Datenbankdesign

[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