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.
da steht dann z.b. folgendes drin
ID, Bezeichnung, Berechungswert
Beispiel: 1, 4/4 Farbig, x.yz
Wenn Deine Größen z.B. S, M, ... usw sind, akzeptiere ich dafür auch eine Tabelle.
ID, Bezeichnung, Höhe, Breite
1, Din A4 lang, x, y
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.
das Problem ist, der Endpreis wird an Hand von Werten berechnet... jede Eigenschaft hat den Faktor x, in der Extra Tabelle wollte ich dafür immer eien Extra Spalte machen, wo die Berechnungswerte drin sind
Was Du mit einer Tabelle für Anzahl willst, das geht über meinen Horizont. Was willst Du damit?
es gibt dann zum Beispiel: 100 Stück, 200, 250, 500, 1000, .... 100000 Stück
jedes Produkt ist in anderen Mengen lieferbar
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.
so toll fand ich es auch nicht, kam nur bei einer Überlegung bei raus ;-)
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 :-)
dann müßte ich noch irgendwo meine Berechnungswerte speichern :-)
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?
Anzahl bedeutet, in welche Menge das Produkt geliefert werden kann
z.B. 10000 Stück
10000 Stück hat dann auch ein Berechnungsfaktor
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?
z.B. 10 Farben, 10 Größen und 20 Mengen * 500 Produkte = 1000000 Datensätze
die Produkte haben aber noch mehr Eigenschaften, z.B. normalerversand, über Nacht, etc.
des wegen meinte ich, ich möchte nicht wissen, wieviele Datensätz1e das dann werden ;-)
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?
ja :-)
Oder doch, aber nicht verstanden? Lies bitte unsere JOIN-Artikel:
ich werd mir das nochmal anschauen, hab gerade nen Knoten im Kopf ;-)
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.
Das Problem ist dann nur das dann die Berechnunsgwerte fehlen, wenn ich in der Produkttabelle die Spalten mache
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.
das verstehe ich jetzt noch nicht so ganz :)
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.
meinst also, für jedes Produkt ein Datensatz?
wenn man es mit SET macht, bekommt ja nicht jede Variation eine ID
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.
das kann ich leider nicht umgehen :-(
mfg
Twilo