Frage zu ERD und NF

S

sqlnewb1253

Neuer Benutzer
Beiträge
3
Hallo zusammen,

ich hoffe ich schreibe hier im richtigen Forum ( habe eine MySQL DB).

Möchte gleich betonen ich frage selbstverständlich NICHT nach kompletten Antworten, mir wären ein paar Tipps und Hinweise am liebsten damit ich mich in die richtige Richtung bewegen kann.

da ich gerade dabei bin SQL zu lernen (als Abwechslung zum "Systemadministratordasein"), dachte ich mir ich probier mal ein kleines Bestellsystem zu erstellen..
Mir ist bewusst dass die Datentypen, Namenskonventionen etc.. noch nicht i. O sind, mir geht es im Prinzip darum ob ich die Sache mit den Beziehungen und NFs richtig habe.

Mein Gedankengang:

Ein Produkt kann mehrere Kategorien haben aber eine Kategorie auch mehrere Produkte, somit eine Jointable und 1:m Beziehung von Kategorie und Produkt auf jene Jointable

Eine Bestellung kann mehrere Produkte haben, aber nur eine Bestellungsnummer somit wieder das gleiche wie bei Kategorie und Produkt.

Ein Benutzer kann mehrere Bestellungen haben, somit 1:n auf tblBestellung

ERD.png


Wenn das richtig ist, dann vermute ich werde ich noch die CONSTRAINTS anpassen muessen oder macht das die workbench bereits richtig?
Damit das ganze dann auch bedienbar ist habe ich vor ein Interface in PHP zu schreiben. --> Da ist dann CRUD angesagt - richtig? Dann wäre es aber auch nicht verkehrt wenn ich eine tbl fuer einen Warenkorb anlege und diese dann irgendwie mit tblJoinBestellungBenutzer verknüpfe?
Gibt es eine internationale Richtlinie für die Benennung von Tabellen, Schlüsseln und sonstigem?
 
Werbung:
deine Kategorien sind Murks. Was machst Du, wenn später nach alkoholische / nichtalkoholische Getränke werden soll? Oder Produkte, wenn Dinge nach Stückzahl gehandelt werden? Und was ist 5 für ein Geschlecht?
 
akretschmer schrieb:
deine Kategorien sind Murks. Was machst Du, wenn später nach alkoholische / nichtalkoholische Getränke werden soll? Oder Produkte, wenn Dinge nach Stückzahl gehandelt werden? Und was ist 5 für ein Geschlecht?
Zum Vergrößern anklicken....

Hallo akretschmer,
erstmal danke für die Antwort,
KATEGORIEN: ich hätte mir gedacht ich füge mit einem INSERT dann die Unterkategorien ein ( https://www.kern.bayern.de/mam/cms03/wissenschaft/dateien/lebensmittelkategorien.pdf ) und wähle sie dann per Formular auf HP aus?
GESCHLECHT: TINYCHAR(1) hätte ich gedacht wegen 0=W 1=M 2=X --> wäre eine bessere Lösung des Problem mit dem Geschlecht via char(1) (m, f, x ) gegeben
STÜCKZAHL: wäre es eine Möglichkeit in der Join Table eine Col. einzufuegen (z.B stueckzahl) und diese dann durch das Formular auf der Homepage einzutragen?
 
Naja, enums sind letztlich eine Form der De-Normalisierung (und sind auch nicht Teil des SQL Standards)

Eine (akademisch) korrekte Lösung wäre ein gender Tabelle mit einem Foreign Key von der Benutzer Tabelle zur Gender Tabelle.
Oder ein CHECK CONSTRAINT auf die Spalte "Geschlecht".

@sqlnewb1253
Präfixe wie "tbl" sind vollkommen überflüssig und häufig eher hinderlich als hilfreich. Natürlich ist das auch eine Geschmacksfrage, aber ich würde Dir empfehlen diesen Präfix ganz wegzulassen.

Du kannst Dir ja mal die Antworten zu diesem Thema hier durchlesen: Is adding the ‘tbl’ prefix to table names really a problem?
 
sqlnewb1253 schrieb:
KATEGORIEN: ich hätte mir gedacht ich füge mit einem INSERT dann die Unterkategorien ein ( https://www.kern.bayern.de/mam/cms03/wissenschaft/dateien/lebensmittelkategorien.pdf ) und wähle sie dann per Formular auf HP aus?
Zum Vergrößern anklicken....
Nicht die Spalten mit den Zeilen verwechseln.
Deine Spalten (Obst, Getränke, Teigwaren,...) sollten Werte der Kategorien sein und keine Spalten.
Was trägst du z.B. bei einem "Apfel" ein?
Eigendlich reicht eine Spalte (Kategorie) und ggf. eine Hirachiespalte (Oberkategorie)

ID|Kategorie|Oberkategorie
-----------------------------
1|Obst|
2|Apfel|1
3|Getränke|
4|Bier|3
5|Wein|3
 
Erstmal danke an alle für die raschen Antworten


Dukel schrieb:
Nicht die Spalten mit den Zeilen verwechseln.
Deine Spalten (Obst, Getränke, Teigwaren,...) sollten Werte der Kategorien sein und keine Spalten.
Was trägst du z.B. bei einem "Apfel" ein?
Eigendlich reicht eine Spalte (Kategorie) und ggf. eine Hirachiespalte (Oberkategorie)

ID|Kategorie|Oberkategorie
-----------------------------
1|Obst|
2|Apfel|1
3|Getränke|
4|Bier|3
5|Wein|3
Zum Vergrößern anklicken....

Hab´s mal angepasst - müsste so hinhauen oder?
castorp schrieb:
Naja, enums sind letztlich eine Form der De-Normalisierung (und sind auch nicht Teil des SQL Standards)

Eine (akademisch) korrekte Lösung wäre ein gender Tabelle mit einem Foreign Key von der Benutzer Tabelle zur Gender Tabelle.
Oder ein CHECK CONSTRAINT auf die Spalte "Geschlecht".

@sqlnewb1253
Präfixe wie "tbl" sind vollkommen überflüssig und häufig eher hinderlich als hilfreich. Natürlich ist das auch eine Geschmacksfrage, aber ich würde Dir empfehlen diesen Präfix ganz wegzulassen.

Du kannst Dir ja mal die Antworten zu diesem Thema hier durchlesen: Is adding the ‘tbl’ prefix to table names really a problem?
Zum Vergrößern anklicken....

Danke, angepasst.



______________


Was mir noch ein wenig Kopfzerbrechen bereitet ist

1) die Sache mit der Stückzahl in der Bestellung, habe in der JoinTable einfach mal stückzahl reingeschrieben (werd´s noch auf INT anpassen) - aber das kommt mir fast zu einfach vor als dass es funktionieren wuerde..

2) Das Handling mit den Fotos, einfacher wäre es vmtl. als blob und foto reinladen
bessere lösung ist wahrscheinlich einfach eine referenz zum pfad des fotos?

EDIT1: Dass die Datentypen noch angepasst werden muessen ist mir bewusst - bin gerade dabei.



ERD.png
 
Werbung:
Zu den Fotos (Dateien in der DB):
Kann man machen, die meisten machen es von der Dateigröße abhängig. Kleine Bilder / Icons ist okay aber wenn es sehr viele Daten werden möchte man sie meiste eher auf dem Dateisystem ablegen. Hier zählt aber auch, was ist eigentlich schneller? Wie gut kann die gewählte DB damit umgehen und wie gut kann die Homepage was laden?

Bestellungen:
Ich würde die Tabelle JoinBestellungBenutzer nicht so nennen, das trifft eigentlich nicht zu, der Benutzer ist hier nicht direkt verknüpft. Abgesehen davon würde ich den Begriff Join nicht im Tabellennamen verwenden. Ich würde das eher als Bestellpositionen bezeichnen.

Geschlecht:
Das in eine Tabelle auszulagern ist natürlich BilderbuchDB aber total umständlich. Niemand will wirklich mehr Speicherplatz nutzen und längere Querys um hier noch mit Fremdschlüsseln zu arbeiten. Wenn du wirklich mit Kunden eines dritten Geschlechts rechnest musst du dir schon gut überlegen ob du diese (nach DSGVO besonders schützenwerte) Information überhaupt speichern willst. Eine Anrede umgeht das datenschutztechnisch eleganter.
 
Zurück
Oben