nicht angemeldet
Hallo
ich hab ein Produkt, was mehrere Eigenschaften haben kann, z.B. Größe, Farben, Anzahl, etc.
für Farbe, Größe, Anzahl möchte ich eine extra Tabelle nehmen
Eigenschaften deuten eher auf Spalten als auf Tabellen :-)
Eine Tabelle für Farbe verstehe ich.
Wenn Deine Größen z.B. S, M, ... usw sind, akzeptiere ich dafür auch eine Tabelle.
In MySQL könntest Du beide mit dem Datentyp SET realisieren. Dies würde Dir die Extra-Tabellen ersparen. Andererseits ist der Datentyp SET auch mit Nachteilen verbunden, wenn es um Erweiterbarkeit geht. Inwieweit Farb- und Größenpalette von vornherein feststehen, das kann ich nicht beurteilen.
Was Du mit einer Tabelle für Anzahl willst, das geht über meinen Horizont. Was willst Du damit?
wenn ich z.B. Farbe 1, Farbe 2, Größe 1, Anzahl 1 und Anzahl 2 hinzufüge gibt es das Produkt in folgenden Varianten
Farbe 1, Größe 1, Anzahl 1
Farbe 1, Größe 1, Anzahl 2
Farbe 2, Größe 1, Anzahl 1
Farbe 2, Größe 1, Anzahl 2das heißt, das Produkt gibt es dann in jeder Variation
ich habe mir bis jetzt 2 Varianten ausgedacht
Variante 1:
die Spalte, Farbe, Anzahl, etc. mache ich als Text und speichere ein serialisiertes Array mit den IDs ab, die zur Verfügung stehen
Arrrgh! Grausam! Schlimmer geht's nimmer! Nein, so nicht!
Willst Du ein Datenbankmanagementsystem vergewaltigen?
Vergiß diese Möglichkeit.
Variante 2:
die Spalte Farbe, Anzahl, etc. bekommen den Typ "Set", nur was mache ich, am Anfang, wenn es noch kein Eintrag in Farbe und Co gibt... Set möchte min ein Eintrag haben
Du musst Deinen Datentyp von vornherein definieren. Im Falle der Farben würde ich eine Tabelle nehmen, im Falle der Größen ein SET :-)
ich möchte ungern für jede Variation ein eigenen Datensatz abspeichern, da z.B. mehr als 10 Farben gibt, von den Mengen kann es unter Umständen mehr als 25 geben, von den Größen gibt es auch einige, + die anderen Eigenschaften
Warum? Das ist völlig problemlos. Ich habe im Moment nur keine Vorstellung, was Deine "anzahl" soll. Inwiefern charakterisiert eine Anzahl Dein Produkt?
bei ca. 500 Produkten, was es mal werden sollen, möchte ich nicht wissen, wieviele Datensätze es dann für ein Produkt geben würde
Verstehe ich nicht?
Der Kunde soll nachher z.B. das Hauptprodukt auswählen... und dann die Eigenschaften auswählen können
Ja und? Wo ist das Problem? Schon mal etwas von JOINS gehört? Nein? Oder doch, aber nicht verstanden? Lies bitte unsere JOIN-Artikel:
Einführung Joins
Fortgeschrittene Join-Techniken.
Insbesondere Rouvens Artikel dürfte für Dich von Interesse sein. Ok, da Du mehr als zwei Tabellen haben wirst, auch meiner.
Nein, Du klatschst nicht alles in eine Tabelle. Nein, Du hältst nicht jede Variation vorrätig. Ja, es ist sinnvoll für Farbe und Größe eigene Tabellen vorzuhalten. Es ist leichter, einer Tabelle einen Datensatz hinzuzufügen als einen Datentyp (SET) zu ändern.
Du hast also die Tabellen:
Produkte (id, produkt, ...)
Farben (id, farbe)
Groessen (id, groesse)
Ein Cross-Join liefert Dir alle möglichen Kombinationen. D.h. wenn Deine Produkttabelle 1000 Produkte umfasst, die Farbtabelle 50 Farben und die Größentabelle 10 Größen, dann hast Du mit diesen 1060 Datensätzen in den drei Tabellen 500.000 verschiedene Produktvariationen drin. Das ist doch was.
Was Dein Kunde macht, das ist eher eine Bestellungposition
Produkt
Farbe
Groesse
Anzahl
Preis :-)
wobei in der Bestellung die entsprechenden IDs stehen, die dem Produkt, der Farbe, der Größe ... entsprechen. Ist ganz einfach. Ist normal. Wird überall gemacht.
als Datenbank kommt MySQL, so wie es aussieht 4.0, zum Einsatz zusammen mit PHP 5.1
MySQL 4.0 ist natürlich ein arges Handicap. Bereits 4.1 kann richtig viel mehr als 4.0. Noch viel besser wäre 5.0.12 und größer, da MySQL ab dieser Version JOINS wesentlich standardkompatibler unterstützt.
Freundliche Grüße
Vinzenz