Datenbankdesign

[Vinzenz Mai]

Hallo

Eine Tabelle für Farbe verstehe ich.

da steht dann z.b. folgendes drin
ID, Bezeichnung, Berechungswert
Beispiel: 1, 4/4 Farbig, x.yz

Was hat das mit Farbe zu tun? Vierfarbdruck, in vier Farben?
Was hat der Berechnungswert zu besagen? x.yz sagt gar nichts aus?
Wovon ist dieser abhängig?

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

Könntest Du das genauer beschreiben. Ein DIN-A-4-Blatt hat für mich genaue Ausmaße. Was bedeuten also Höhe und Breite?

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

Ja, wo ist das Problem? Berechnungen sind sehr einfach durchzuführen? Was sollen diese Berechnungswerte? Verstehe ich nicht.

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

Ah ja, Stückzahlen mit Stückzahlabhängigen Konditionen. OK, nimm eine Tabelle, mit Tabellenwerten läßt es sich leichter rechnen. SET und ENUM sind Zeichenketten, deswegen meiner Meinung nach nicht die richtige Wahl.

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 :-)

Bitte erläutere diese "Berechnungswerte" genauer. Ich kann mir darunter alles und nichts vorstellen. Auf jeden Fall solltest Du für Deine "Farben" eine Tabelle nehmen. Unter Farben hatte ich mir ganz einfach "Blau", "Gelb", "Grün", "Rot", ... vorgestellt. Du jedoch etwas anderes.

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

Nein, Du benötigst keine Million Datensätze. Du schreibst es doch schon selbst:

10 + 10 + 20 + 500,

das sind ganze 540 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 ;-)

ein paar mehr. Aber wahrscheinlich nicht wesentlich mehr.

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 :-)

Dann hast Du JOINS definitiv nicht verstanden. Lies bitte.

Du hast also die Tabellen:

Produkte (id, produkt, ...)
Farben (id, farbe)
Groessen (id, groesse)

Mengen (id, stueckzahl)

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 :)

Du kannst mit diesen Datensätzen in einer weiteren Tabelle (einer Verknüpfungstabelle) bei Bedarf jede dieser 500.000 Variationen erstellen.

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?

ja, selbstverständlich. Bei 500 Produkten macht das 500 Datensätze, egal wieviele Farben es gibt, wieviele Größen, wieviele Mengen, wieviele Sonderbestimmungen, es bleiben 500 Produktdatensätze.

Bei 20 "Farbvariationen" 20 Datensätze in der Farbtabelle,
bei 10 "Größen" 10 Datensätze in der Größentabelle,
bei 20 "Mengen" 20 Datensätze in der Mengentabelle.

Gibt es eine weitere Größe, so gibt es genau einen weiteren Datensatz in der Tabelle Größen. Bei Bedarf kann dieser in einer Bestellposition mit allen Farbvariationen und allen Stückzahlen kombiniert werden. Bei Bedarf. Bei einer Bestellung (oder was auch immer). Nicht vorher.

Du hältst nicht jede mögliche Kombination "auf Vorrat". Du kannst Dir bei Bedarf die nötige Kombination zusammenbauen. Soviele unterschiedliche Bestellpositionen von unterschiedlichen Kunden, soviele Datensätze. Diese musst Du eh' erfassen. Je mehr desto besser :-)

wenn man es mit SET macht, bekommt ja nicht jede Variation eine ID

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 :-(

Aufrichtiges Beileid.

Freundliche Grüße

Vinzenz