Datenbankdesign

[malta]

Hallo,

ich habe einen bestehenden Shop mit folgenden
Tabellen:

1. Bestellung
id | kundenId | datum | etc

2. bestelldetails
id | bestellId |anzahl | preis |etc

3. artikel
id | name | beschreibung | preis
1 | o-saft | blabla | ..
2 | maracujasaft | .. | ..

Jetzt möchte ich nicht mehr nur säfte anbieten, sondern auch Cocktails, die aus den säften bestehen. wie würdet ihr das erweitern, lösen?

den Cocktail einfach nur als Artikel einfügen möchte ich nicht, da ich anhand der bestelldetails tabelle auch den aft verbrauch ermittle und user eigene Cocktails kreieren können sollen..

Kann mir da jmd helfen?

Gruß und Dank

[dimitri]

Hi,

zum einen solltest Du die Tabelle Artikel in Saft umbenennen, denn es handelt sich ja augenscheinlich nicht um eine allgemeine Artikeltabelle.
Jetzt brauchst Du eine weitere Tabelle Cocktail, in der allgemeine Daten zu dem Getränk enthalten sind. Jetzt eine Zuordnungstabelle Cocktailrezept, die eine Verbindung von Cocktail zu Saft herstellt.
Wegen der Bestelldetails müsste man jetzt mehr Details wissen. Reicht es Dir, wenn dort bei der Auswahl eines Cocktails nur die benötigten Säfte reingeschrieben werden, oder möchtest Du auch wissen, dass es sich um einen Cocktail gehandelt hat? Letzteres macht es natürlich noch etwas komplexer.

Dim

[malta]

So, ich habe mir jetzt erstmal mySQL Workbench geladen und werde damit das modelling probieren..
Ich melde mich dazu nochmal..

Danke für die Denkanstöße!

[malta]

so, habe ich das jetzt gelöst..
Was hälst Du davon?

http://twitpic.com/5gid4z

[dimitri]

Da gibts so einiges, was man noch optimieren könnte:
Fangen wir mit Bestellung an:
1. Du speicherst in dieser Tabelle die Fremdschlüssel für diverse weitere Tabellen. Das ist falsch. Bestellung ist die übergeordnete Tabelle und wird daher von den untergeordneten Tabellen referenziert (oder anders gesagt es gibt keinen Bestellstatus ohne Bestellung - laut deinem Modell müsste es aber genau so angelegt werden).
2. Du hast unnötige 1:1 Beziehungen. Die Tabellen bestellung_bestellstatus und bestellung_bezahlstatus sollten nicht ausgelagert werden. Es gibt jeweils genau einen Eintrag dazu und der gehört in die Tabelle Bestellung. Du machst Durch solche Modellierungen das ganze unnötig komplex. Sowohl vom Datenmodell als auch von der späteren Programmierung
3. Wenn Du den Bestellort auslagerst, dann sollte schon etwas mehr drinnen stehen als nur der Name.
4. Ein Kunde kann nach Deinem Midell nur eine Adresse haben. Schon eine abweichende Liefer- bzw. Rechnungsadresse könntest Du nicht mehr abbilden. Hier handelt es sich um eine klassische 1:n Verknüpfung, die auch so abgebildet werden sollte.
5. In der Tabelle Kunden speicherst Du wieder den Fremdschlüssel zu kunden_marketing und anderen Tabellen. Zum einen gehören diese Felder raus und statt dessen in die abhängigen Tabellen die Kunden, zum anderen musst Du darauf achten, dass die Spaltentypen identisch sind. Nicht einmal VARCHAR in der einen und dann INT in der anderen Tabellen.

Fazit: Raus mit den 1:1 Beziehungen, Adressen auslagern und für PK-FK Beziehungen immer den gleichen Datentyp in den jeweiligen Spalten verwenden.

Dim

[malta]

Hallo Dimitri,

vielen Dank für Deine Antwort!

Zu 1 & 2)
Hast Du Dir den bezahl- und bestellstatus so vorgestellt:
http://twitpic.com/5ii7ld

Zu 3 & 4)
bestellung_orte ist 'quasi' die lieferadresse / abholadresse (geliefert wird nicht, nur abgeholt)
Eine abweichende Rechnungsadresse würde mit einem neuen kundenAccount gelöst werden..

Zu 5)
Kunden_marketing soll also wie bestellstatus gelöst werden?
Die Datentypen sind klar, da kümmere ich mich noch drum..

Vielen Dank im vorraus!

[dimitri]

Jetzt machst Dus noch komplexer. Der Bestellstatus wird jetzt auch noch über eine Zwischentabelle aufgelöst
Eine Bestellung kann laut Deinem Modell genau einen Status haben d.h. Du machst ein neues Feld Status in BESTELLUNG und löscht die Tabellen bestellung_bestellstatus und bestellstatus.
Gleiches gilt für den Bezahlstatus oder Kunden_marketing. Das sind 1:1 Beziehungen bzw. ist bei der momentan so abgebildet und sollte daher in eine Tabelle

Eine abweichende Rechnungsadresse würde mit einem neuen kundenAccount gelöst werden

Ist das eine fachliche Vorgabe? In diesem fall musst Du nämlich aich noch eine Tabelle einführen, in der vermerkt wird, dass es sich bei zwei Kunden um Dubletten handelt, die nur deshalb existieren, weil eine abweichende Rechnungsanschrift benötigt wurde. Ich kann von so einem Vorgehen aber nur abraten. Ein Kunde hat eine oder mehrere Adressen.

Dann gibts übrigends noch doppelte Felder. Preis ist z.B. in Bestelldetails und in Artikel enthalten. Aus Bestelldetails gehört der raus - das wird Berechnet aus dem Artikelpreis und der Anzahl der Artikel.

Dim