nicht angemeldet
mySQL: Sinnvolles Datenbank-Design / Normalisierung
Hallo,
ich mache grade eine Art "Multi-Media" Portal - Benutzer können also verschiedene Arten von Medien hochladen: Videos, Audio, Bilder und Texte. Das Ganze ist mehr eine Übung für mich selbst.
Ich versuche grade mit der MySQL Workbench ein sinnvolles Datenbank-Design umzusetzen.
Ich dachte, ich mache eine Tabelle "content" - da wird jede Art von hochgeladenem Content abgelegt. Eine ergänzende Tabelle "types" legt fest, um welche Art von Content es sich handelt (audio, video, image, text). "categories" teilt den Content in Kategorien ein (zuhause, sport, urlaub, wasweißich).
content
- content_id, INT(10), PRIMARY KEY
- user_id, INT(10), FOREIGN KEY, Referenz zu Tabelle "users" => user_id
- filename, VARCHAR(50)
- added, DATE
- title, VARCHAR(50)
- description, VARCHAR(250)
- views, INT(10)
- cat_id, INT(10), FOREIGN KEY, Referenz zu Tabelle "categories" => cat_id
- type_id, INT(1), FOREIGN KEY, Referenz zu Tabelle "types" => type_id
types
- type_id, INT(1), PRIMARY KEY
- type_name, CHAR(5)
categories
- cat_id, INT(10), PRIMARY KEY
- cat_name, VARCHAR(50)
So weit, so gut. Ich habs etwas gekürzt, ich hoffe man steigt noch gut durch. Jetzt stehe ich aber vor der Situation: Wenn der Content ein Video ist, soll zusätzlich noch die Länge des Videos gespeichert werden. Wenn der Content dagegen ein Bild ist, soll das Bild einer der verfügbaren Bilder-Gallerien zugeordnet werden.
Es sind also zusätzliche Tabellen nötig, die aber nicht immer gebraucht werden. Ist das ein Problem? Oder kann ich zb einfach eine Tabelle "video_length" erstellen und eine 1:1 Beziehung zur Tabelle "content" herstellen? In die Tabelle "video_length" wird dann natürlich nur etwas eingetragen, wenn es sich um ein Video handelt.
Bei Bildern mit den Galleries ist das ähnlich. Ist das ein Problem, oder kann man das problemlos machen? Oder würdet ihr das ganz anders machen?
Grüße
Sven
-
Hallo
nur mal so eine Idee,
eine zusätzliche Tabelle "content_options" mit Beziehung zu Content und Types und einer Spalte "Description" oder "Options"
ContenOptionID, ContentID, TypeID, Option
1, 2, 3, 20min
2, 2, 1, blabla
...
viele Grüße
hawk -
moin,
erst mal noch ein kleiner hinweis für dich. tabellennamen sollte man einheitlich im singular halten, hat sich so "eingebürgert" und ich halte es auch für sinnvoll.
Jetzt stehe ich aber vor der Situation: Wenn der Content ein Video ist, soll zusätzlich noch die Länge des Videos gespeichert werden. Wenn der Content dagegen ein Bild ist, soll das Bild einer der verfügbaren Bilder-Gallerien zugeordnet werden.
das problem geht ein wenig in das thema objektorientierung hinein. nur lassen sich relationale dbms und objektorientierte ansätze schwer miteineinander verheiraten. man hat quasi gemeinsame attribute, die immer vorkommen aber auch wieder spezifische, die je nach typ sich unterscheiden. die hersteller versuchen schon lange dieses problem bei rdbms zu lösen, meiner meinung nach ohne erfolg. mein tip an dich wäre, trenne die verschiedenen entittypen voneinander, wenn sie sich in den attributen unterscheiden. es gibt fälle, da ist das nicht möglich, zum beispiel weil die attribute und somit das daten-design sehr dynamisch ist. aber das scheint mir hier nicht der fall zu sein.
Es sind also zusätzliche Tabellen nötig, die aber nicht immer gebraucht werden. Ist das ein Problem? Oder kann ich zb einfach eine Tabelle "video_length" erstellen und eine 1:1 Beziehung zur Tabelle "content" herstellen? In die Tabelle "video_length" wird dann natürlich nur etwas eingetragen, wenn es sich um ein Video handelt.
das problem bei dieser lösung ist, dass du abhängig von den typen unterschiedliche JOINs bilden müsstest, was alles komplizierter macht. ich würde davon abraten.
Ilja