Datenbankdesign

[Twilo]

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?

Als Farbe ist nicht gelb oder blau gemeint, sondern 4/4, 4/1, 4/0, 2/0, 2/1 etc.

so ein Eintrag hat für die Preisberechnung ein bestimmten Faktor

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?

ja, DIN A4 hat gewisse Maße 297*210

um den Preis nachher Berechnen zu können, brauche ich dann als Höhe 297 und als Breite 210
bei Din A4 Lang sind die Maße etwas anders ;-)

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.

damit wird am Ende der Preis für den Kunden berechnet

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.

ich hatte mir es so gedacht, wenn man eine Option über den Adminbereich neu zur Verfügung stellt, dass dann die Spalte mit den Set Werten geändert wird

welche Möglichkeit besteht denn noch, wie ich mir die ID's merken kann, die ein Produkt zur Verfügung hat?

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.

Der Produkt wird je nach Option berechnet
ein Produkt hat Standardwerte, die dann multipliziert, addiert, etc. mit den Optionen den Endpreis für das ausgewählte Produkt ergeben

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

10 + 10 + 20 + 500,

das sind ganze 540 Datensätze.

und wie speicher ich am sinnvollsten, welche Optuionen für Produkt xy zur Verfügung stehen

also z.B. bei den Mengen, z.b. ID 1, ID 2, etc.
ID 1, etc. stehen dann z.B. für 100 Stück

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.

wenn alle Eigenschaften für jedes Produkt zur Verfügung stehen würde, würde das so klappen

einige haben aber z.B. nur Farbe 1 und Farbe 3, das andere Produkt jedoch nur Farbe 2

somit müßte ich irgendwo speichern, welches Produkt welche Eigenschaften hat

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.

danke ;-)

mfg
Twilo