Datenbankdesign

[Twilo]

Hallo,

wie würdet ihr folgendes Problem lösen...

ich hab ein Produkt, was mehrere Eigenschaften haben kann, z.B. Größe, Farben, Anzahl, etc.

z.B. Produkt A:
Größe 1, Größe 2, Farbe 1, Anzahl 1 Anzahl 2 Anzahl 3, Anzahl 4

Produkt B:
Größe 1, Farbe 1, Farbe 2, Farbe 3, Anzahl 1

für Farbe, Größe, Anzahl möchte ich eine extra Tabelle nehmen

dann eine Tabelle z.B. Produkt, + Spalte Farbe, Anzahl, Größe

mein Problem ist nun folgendes

ich erstelle zuerst ein Produkt und anschließen füge ich die Eigenschaften hinzu

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 2

das 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

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

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

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

Der Kunde soll nachher z.B. das Hauptprodukt auswählen... und dann die Eigenschaften auswählen können

wie würdet ihr soetwas lösen?
hat vielleicht jemand eine Quelle, wo so ein Szenario beschrieben ist?

mfg
Twilo

[Twilo]

Hallo,

ich hab ganz vergessen:

als Datenbank kommt MySQL, so wie es aussieht 4.0, zum Einsatz zusammen mit PHP 5.1

mfg
Twilo

[Vinzenz Mai]

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 2

das 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

[Twilo]

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:

Einführung Joins
Fortgeschrittene Join-Techniken.

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

[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

[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

[Vinzenz Mai]

Hallo Twilo,

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

das ist überhaupt kein Problem

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

210x297, oder nicht?

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

Wie sieht die Berechungsvorschrift aus? Ich kann mir nicht vorstellen, dass sich diese nicht sehr einfach darstellen läßt. Ohne Genaueres zu wissen, kann man Dir nicht konkreter helfen. Ich vermute, dass es einfach ist :-)

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

Warum eine Zeichenkette? Was bringt Dir diese?
Warum willst Du nicht einfach eine INSERT-Anweisung durchführen?
Das ist meiner Meinung nach viel, viel einfacher?
Warum willst Du es unnötig komplex haben?

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

Ich verstehe diesen Satz nicht. Du musst Dir überhaupt keine IDs merken. Diese sind nur für interne Zwecke relevant.

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

Wo ist das Problem. DBMS können wunderbar rechnen, sie können multiplizieren, addieren, subtrahieren, dividieren, ...

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

Ja, in Verknüpfungstabellen, z.B. in diesem konkreten Fall:
    Produkt <-> Farbzuordnung.
Für erlaubte andere erlaubte Kombinationen gehe analog vor.

Der Knackpunkt ist doch gerade, nicht alles in eine Tabelle zu quetschen. Dafür gibt es JOINs.

Freundliche Grüße

Vinzenz

[Twilo]

Hallo,

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

210x297, oder nicht?

öhm...
ehrlich gesagt keine Ahnung, die Werte habe ich noch nicht erhalten :-)

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

Wie sieht die Berechungsvorschrift aus? Ich kann mir nicht vorstellen, dass sich diese nicht sehr einfach darstellen läßt. Ohne Genaueres zu wissen, kann man Dir nicht konkreter helfen. Ich vermute, dass es einfach ist :-)

der Preis setzt sich aus 14 Variablen zusammen
dann werden ein Paar Zwischenergebnisse (laut Vorgabe im Moment 9) berechnet, gerundet etc.

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

Warum eine Zeichenkette? Was bringt Dir diese?
Warum willst Du nicht einfach eine INSERT-Anweisung durchführen?
Das ist meiner Meinung nach viel, viel einfacher?
Warum willst Du es unnötig komplex haben?

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

Ich verstehe diesen Satz nicht. Du musst Dir überhaupt keine IDs merken. Diese sind nur für interne Zwecke relevant.

na ich hab doch eine Tabelle, wo alle Arten von Farben drin stehen, dann eien Tabelle wo alle Mengen drin sind, etc.

wenn die ID nicht gemerkt werden, woher soll ich oder die Datenbank dann wissen, welche Option welches Produkt zur Verfügung hat, wenn ich das nicht irgendwo speicher?

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

Wo ist das Problem. DBMS können wunderbar rechnen, sie können multiplizieren, addieren, subtrahieren, dividieren, ...

können die auch Zwischenergebnisse berechnen?
und diese dann mehrmals verwenden?

einfache Berechnung habe ich damit schon vorgenommen, aber soetwas noch nicht :)

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

Ja, in Verknüpfungstabellen, z.B. in diesem konkreten Fall:
    Produkt <-> Farbzuordnung.
Für erlaubte andere erlaubte Kombinationen gehe analog vor.

und woher bekomem ich die Kombinationen, wenn ich diese nicht separat speichenr soll/darf?

Beispiel:
Tabelle Anzahl
+----+-------------+--------+
| ID | Bezeichnung | Faktor |
+----+-------------+--------+
| 1  | 100 Stück   | x.y    |
+----+-------------+--------+
| 2  | 200 Stück   | x.y    |
+----+-------------+--------+
| 3  | 250 Stück   | x.y    |
+----+-------------+--------+
| 4  | 500 Stück   | x.y    |
+----+-------------+--------+
| 5  | 750 Stück   | x.y    |
+----+-------------+--------+
| 6  | 1000 Stück  | x.y    |
+----+-------------+--------+
| 7  | 2500 Stück  | x.y    |
+----+-------------+--------+
| 8  | 5000 Stück  | x.y    |
+----+-------------+--------+
| 9  | 10000 Stück | x.y    |
+----+-------------+--------+
| 10 | 15000 Stück | x.y    |
+----+-------------+--------+
| 11 | 20000 Stück | x.y    |
+----+-------------+--------+
| 12 | 25000 Stück | x.y    |
+----+-------------+--------+
| y  | y Stück     | x.y    |
+----+-------------+--------+

Produkt A hat z. B. folgende Mengen zur Auswahl ID 1,2,3,4
Produkt B ID 1,2,5,10
Produkt C ID x,y,z

woher weiß ich, dass Produkt A die Mengen 1,2,3,4 hat, wenn ich das nirgends speichere, oder habe ich was überlesen oder falsch verstanden?

mfg
Twilo

[Vinzenz Mai]

Hallo

Ich verstehe diesen Satz nicht. Du musst Dir überhaupt keine IDs merken. Diese sind nur für interne Zwecke relevant.
wenn die ID nicht gemerkt werden, woher soll ich oder die Datenbank dann wissen, welche Option welches Produkt zur Verfügung hat, wenn ich das nicht irgendwo speicher?

ich glaube, da redeten wir aneinander vorbei :-)

Ja, in Verknüpfungstabellen, z.B. in diesem konkreten Fall:
    Produkt <-> Farbzuordnung.
Für erlaubte andere erlaubte Kombinationen gehe analog vor.

und woher bekomem ich die Kombinationen, wenn ich diese nicht separat speichenr soll/darf?

Beispiel:
Tabelle Anzahl

ID | Bezeichnung | Faktor |
+----+-------------+--------+
1  | 100 Stück   | x.y    |
2  | 200 Stück   | x.y    |
3  | 250 Stück   | x.y    |
4  | 500 Stück   | x.y    |
5  | 750 Stück   | x.y    |
6  | 1000 Stück  | x.y    |
7  | 2500 Stück  | x.y    |
8  | 5000 Stück  | x.y    |
9  | 10000 Stück | x.y    |
10 | 15000 Stück | x.y    |
11 | 20000 Stück | x.y    |
12 | 25000 Stück | x.y    |

Produkt A hat z. B. folgende Mengen zur Auswahl ID 1,2,3,4
Produkt B ID 1,2,5,10
Produkt C ID x,y,z

Nehmen wir an: Tabelle Produkte

ID  Produkt
--------------
 1  Produkt A
 2  Produkt B
 3  Produkt C

Dann sähe Deine Verknüpfungstabelle wie folgt aus:

Mengen_Produkt

ID_Produkt  ID_Menge
---------------------
 1           1
 1           2
 1           3
 1           4
 2           1
 2           2
 2           5
 2          10
 3           x
 3           y
 3           z

Sollte Dein "Mengenfaktor" produktabhängig sein, dann würdest Du dieses Attribut _nicht_ in der Tabelle Anzahl, sondern in dieser Verknüpfungstabelle mitführen.

Freundliche Grüße

Vinzenz

[Twilo]

Hallo,

Dann sähe Deine Verknüpfungstabelle wie folgt aus:

Mengen_Produkt

ID_Produkt  ID_Menge

1           1
1           2
1           3
1           4
2           1
2           2
2           5
2          10
3           x
3           y
3           z

Sollte Dein "Mengenfaktor" produktabhängig sein, dann würdest Du dieses Attribut _nicht_ in der Tabelle Anzahl, sondern in dieser Verknüpfungstabelle mitführen.

ok, jetzt hab ich es verstanden :-)

ist eine n:m Beziehung, oder?

mfg
Twilo

[at]

Hallo.

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

Wäre es nicht sinnvol, die Werte für die Vorder- und die Rückseite getrennt abzulegen? Je nach Kalkulationsfaktor müsste man sie dann zur Berechnung nicht mehr zerlegen, sondern nur noch für die Ausgabe zusammensetzen -- falls man denn die Bezeichnungen überhaupt beibehalten möchte.
MfG, at

[at]

Hallo.

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?

• Überformate: Wenn du etwas bündig mit dem Rand des Papiers drucken möchtest, erhältst du entweder einen minimalen weißen Rand oder die Maschine druckt auch ein wenig neben das Papier, von wo aus die Farbe auch auf die Rückseite gelangen kann. Um das zu vermeiden, wird einfach größeres Papier verwendet und hinterher auf das gewünschte Maß beschnitten.
• Nutzen
  MfG, at

[Ilja]

yo,

ich habe nicht den ganzen dialog von Vinzenz und dir gelesen, sind ja wahre romane. ich will noch eine andere möglichkeit mit ins spiel bringen. aber bevor ich das mache, würde ich dir noch ans herz legen, für das datenbank-design einen profi zu angagieren. ich habe gerade erst am wochenende wieder einen bekannten eines bekannten getroffen, der auch mal auf die schnelle ein datenbank mit access erstellen sollte und dann natürlich probleme mit den abfragen bekommen hat, weil vieles flickwert war. ein daten-design geht eben nicht mal auf die schnelle zu entwickeln und hat viele folge-konsequenzen, wenn es nicht ordentlich erstellt wurde. ein investition in einen profi kann viel zeit, stress und geld im nachhinein sparen.

was die version von mysql betrifft, so gibt es nicht sehr viele gründe noch 4.0 weiterhin zu verwenden. ich würde Vinzenz tipp beherzigen es mindestens auf 4.1 umzustellen. auch wenn es schon eine datenbank in der version 4.0 gibt und programme darauf ausgerichtet wurden, sollte man sich das sehr gut überlegen, immer weiter auf die alte version zu setzen. lieber rechtzeitig einen schnitt machen.

ok, genug der vorworte, jetzt erst einmal ans eingemachte. in die datenbank müssen natürlich die verschiedenen kombinationsmöglichkeiten der jeweiligen produkte abgelegt werden. dass du da nicht jede kombination expliziet eintragen musst, dass hat dir Vinzenz schon deutlich gemacht. wichtig ist ja nur, dass die datenbank zum produkt A die möglichen farben, größen, etc. zur Auswahl widergibt. es reicht also, wenn du zu jedem produkt die möglichen eigenschaften speicherst. was die anzahl der datensätze betrifft, so will ich das nach meinen modell erklären.

ich würde im gegensatz zu Vinzenz nicht für jede eigenschaft wie farbe, größe, anzahl, etc eine extra Tabelle nehmen. ein problem ist, dass bei größereren datenmengen viele tabellen dazu führen können, dass die performance stark einbricht. hängt aber auch von anderen faktoren ab. aber was wesentlich dramatischer ist, sollten neue eigenschaften hinzukommen, dann muss man zwangsweise in das daten-design eingreifen. und das ist in aller regel keine gute sache, weil alles was hinter der datenbank hängt (programme) automatisch mit geändert werden müssen.

deswegen würde ich dir vorschlagen, eine tabelle für die produkte zu machen und eine tabelle für die eigenschaften. in der tabelle für die produkte stehen natürlich attribute wie produktname, etc. interessanter ist die tabelle mit den eigenschaften. dort stehen alle eigenschaften, die deine produkte besitzen können und zwar nur die eigenschaften. das wären also:

• farbe
• groesse
• anzahl
• etc.

da beide tabellen produkte und eigenschaften in einer n:m beziehung stehen, kommt eine dritte beziehungstabelle ins spiel. und genau dort wird dann festgehalten, welches produkte welche eigenschaft mit welchen inhalt besitzen kann. beispiel:

die beziehungstabelle (produkte_eigenschaften) hat folgende spalten

produkt_id, eigenschaft_id, wert

dann würde in der tabelle für produkt_a die entsprechende id in der ersten spalte stehen, in der zweiten spalte die id der jeweiligen eigenschaft, zum beispiel farbe und in der spalte wert halt der jeweilige wert 1/4.

damit wird auch klar, wieviele datensätze du eintragen musst, das sind:

anzahl produkte in der produkttabelle + anzahl der eigenschaften in der eigenschaftstabelle + anzahl der werte der eingenschaften der jeweiligen produkte. du siehst, die anzahl addiert und multipliziert sich nicht.

Ilja

[Twilo]

Hallo,

danke für deine Antwort

die beziehungstabelle (produkte_eigenschaften) hat folgende spalten

produkt_id, eigenschaft_id, wert

dann würde in der tabelle für produkt_a die entsprechende id in der ersten spalte stehen, in der zweiten spalte die id der jeweiligen eigenschaft, zum beispiel farbe und in der spalte wert halt der jeweilige wert 1/4.

das mit der zusätzlichen Tsbelle verstehe ich, aber wofür ist die Spalte "wert" und warum ein viertel?

Fragen über Fragen :-)

mfg
Twilo

[Ilja]

yo,

das mit der zusätzlichen Tsbelle verstehe ich, aber wofür ist die Spalte "wert" und warum ein viertel?

du hast zwei tabellen, zum einen die produkt_tabelle, da stehen natürlich alle produtkte drinne. dann hast du einen zweite eigenschaften_tabelle, wo "nur" die unterschiedlichen eigenschaften drinne stehen, sprich nicht etwas alle farben, sondern nur die eigenschaft farbe, quasi ein datenstz für farbe, ein datensatz für anzahl, etc.

beide tabellen stehen in einer n:m beziehung, sprich jedes produkt kann mehrere eigenschaften haben und jede eigenschaft mehrere produkte. ergo brauchst du eine weitere beziehungstabelle, um sie abbildungen zu können. dort steht dann auch der wert der farbe. ich werde mal Vinzenz folgen und dann hätte die spalte werte für farben zum beispiel den inhalt grün, rot oder blau. schließlich musst du ja irgendwo festhalten, welche farbe nun letztlich ein produkt haben kann.

Ilja

[at]

Hallo.

ich werde mal Vinzenz folgen und dann hätte die spalte werte für farben zum beispiel den inhalt grün, rot oder blau. schließlich musst du ja irgendwo festhalten, welche farbe nun letztlich ein produkt haben kann.

Dann folgst du ihm in die Irre, denn offenbar handelt es sich um die Kalkulation von Druckpreisen.
Ein nur einseitig und einfarbarbig bedruckter Bogen wird als "1/0-farbig" bezeichnet, ein beidseitig vollfarbiger CMYK-Druck als "4/4-farbig". Wenn prinzipiell keine Sonderfarben gedruckt werden, also die Druckmaschine nicht mit anderen Farben als Cyan, Magenta, Gelb und Schwarz befüllt wird, spielt der Farbname letztlich keine Rolle.
MfG, at

[Ilja]

yo,

Dann folgst du ihm in die Irre, denn offenbar handelt es sich um die Kalkulation von Druckpreisen.

nein, er weiss schon genau, was mit farbe gemeint ist. deswegen habe ich ja auch erwähnt, dass ich Vinzenz folgen will. für ihn und mich sind farben nun mal blau, grün.....diese altertümlichen werte für farben kann er dann nach belieben ersetzen.

Ilja

[at]

Hallo.

deswegen habe ich ja auch erwähnt, dass ich Vinzenz folgen will. für ihn und mich sind farben nun mal blau, grün.....diese altertümlichen werte für farben kann er dann nach belieben ersetzen.

Es gibt nichts zu ersetzen, weil die Farben keine Namen haben, sondern nur eine Anzahl.
MfG, at

[Ilja]

yo,

Es gibt nichts zu ersetzen, weil die Farben keine Namen haben, sondern nur eine Anzahl.

scheinbar macht Twilo da aber einen unterschied zwischen farben und anzahl.

Ilja

[at]

Hallo.

scheinbar macht Twilo da aber einen unterschied zwischen farben und anzahl.

Stimmt, scheinbar.
MfG, at