Hallo,

ich stelle mir die Frage, wie ich am Besten eine Datenbank realisiere. Das konzept ist folgendes:

Ich habe eine Anleitung für Produkte mit AnleitungsID, Titel, Anleitungstext, Material. Diese Anleitung kann für mehrere Produkte genutzt werden. Ich sage mal durchschnittlich 20. Und diese Anleitung kann bewertet werden.

Die Struktur sieht also folgendermaßen aus:
AnleitungsID | AutorID | Titel | Anleitungstext | Material | Produkt | Bewertung | Datum

Dafür habe ich auf die Spalte Produkt einen Primary Key und Volltextsuche gesetzt. D.h. ich schreibe alle Produkt IDs, die zu dieser passen, in das Feld Produkte und trenne es z.B. durch ein Semikolon. Das gleiche mache ich für die Spalte Bewertung mit den USERIDs, nur dass ich diese ja nicht durchsuchen muss, sondern nur die IDs speichere. Daher hier keine Volltextsuche.

Produkt = 400;323;456;324;900;5000;372;1;19;usw;

Möglicherweise sähen Bewertungen auch so aus:

Bewertung = 400|1;200|2;100|4;usw;

Ich lese die Bewertungen ja nur aus. In diesem Falle würde die erste Ziffer die ID des Nutzers sein getrennt durch einen Strich von seiner abgegebenen Bewertung. Also hier Nutzer mit ID 400 gibt 1 Bewertungspunkt ab, Nutzer mit ID 200 gibt schon 2 Bewertungspunkte ab. Das ganze muss ja dann nur ausgelesen werden, wenn ich die benötigten Anleitungen gefunden habe. Statt dem | würde ich sogar zu einem => tendieren, um das so direkt in Arrays zu schreiben wie auch immer, je nach bedarf.

In meinem Test bei 10.000 Datensätzen (Anleitungen) und genau 1000 Produkt IDs in dem Feld, habe ich bei Volltextsuchen 0.0004 Sekunden benötigt um Datensätze zu erhalten, die einer bestimmten Produkt ID entsprachen.

Jetzt ist aber ein Freund gekommen und meinte, es ginge anders schneller. Und zwar indem ich mehrere Tabellen mache und dann bei der Abfrage durch joins verbinde. Quasi sähe die Struktur dann so aus:

Anleitungen:
AnleitungsID | AutorID | Titel | Anleitungstext | Material | Datum

Bewertungen:
BewID | AnleitungsID | UserID | Bewertungspunkte

AnleitungenProdukte
ProduktID | AnleitungsID

Diese hätte ich auch bei der anderen Variante:
Produkte
ProduktID | Eigenschaften... | Eigenschaften... | Eigenschaften...

Prinzip 3 Tabellen die ich bei allen Abfragen beachten muss gegen eine. Plus den zusätzlichen Programmieraufwand, wenn ich z.B. Datensätze löschen möchte. Sagen wir mal das wäre gegenüber der Performance außer Acht zu lassen.

Nur was ich vorher ich sage mal mit 10000 Datensätzen geschafft habe, wo ich meine 20 Produkt IDs drinne habe, brauche ich ja nach dieser Tabellenordnung die mein Freund vorschlägt, 10000 mal 20 Datensätze, also 200000 Stück um das gleiche abzubilden. Und zwar satte 2 mal, also 400.000 Datensätze. Hier sind die Bewertungen noch garnicht mit drinne, wobei das noch sehr moderat ausfiele, kommt eben auf die Anzahl der Bewertungen an. Wenn es 4 Bewertungen sind, wen juckt das schon. Aber 5000 Bewertungen sind auch wieder 5000 Datensätze und rechnet man das auf 10.000 Anleitungen hoch, stehe ich mit 50.000.000 Datensätzen da in einer Tabelle. Nicht dass eine Anleitung soviele Bewertungen erhielte, aber es streckt sich ja über die Anzahl der Anleitungen hinweg.

Noch dazu die joins, die Tabellen die angesprochen werden müssen.

Es würde mich interessieren, wie ihr das seht, ob ihr schon Erfahrung mit so Sachen habt. Ist das wirklich schneller? Um wie viel? Wie sieht es bei sehr vielen Datensätzen aus?

MfG,
Rolf