Feedback über Musikdatenbank Entwurf

Crazy-X

Hi,

ich plane zur Zeit ein großes Musikdatenbank-Projekt. BTW: Falls Interesse besteht mitzuwirken, hier ist die entsprechende Projektseite: http://home.arcor.de/crazy-x/musicfire

Es geht darum eine Datenbank zur Musikrecherche und zum Verwalten einer Musiksammlung zu entwickeln. Die Stammdaten sind z.B. Interpreten, Infos über diese und ihre Lieder. Welche Alben haben sie veröffentlicht und wann...
Die Benutzerdaten dagegen, speichern und verwalten welche Lieder der Benutzer in seiner Sammlung besitzt.

Meinen anfänglichen Datenbank Entwurf dafür, habe ich immer weiter verbessert und neue Ideen hinzugefügt und bin nun zu 3 verschiedenen "Ergebnissen" gekommen, die der Reihe nach "detailreicher" werden. Da ich allerdings noch nicht sehr viel Erfahrung mit Datenbanken habe, mir dieses Projekt aber sehr ernst ist, wollte ich hier mal fragen, was ihr von meinen Entwürfen haltet.

Meine ersten Test (mit Version 1) haben bisher zwar keine Probleme bereitet. Aber bekanntlichermaßen bemerkt man Designfehler meistens selbst erst zu spät. Deshalb wäre mir in dieser Phase Feedback von erfahreneren Leuten sehr hilfreich.

Version 1: http://home.arcor.de/crazy-x/musicfire/musicfire1.png

Vieleicht noch ein paar Bemerkungen dazu:

Bei der Tabelle "Lied", geben AlbumID und Jahr an, auf welchem Album und in welchem Jahr das Lied veröffentlicht wurde. Das Jahr habe ich nochmal extra in der Tabelle, damit man ggf. auch noch das Jahr festlegen kann, wenn man das Erscheinungs-Album nicht kennt.

In der Tabelle "Album" wird auch extra nochmal der Interpret aufgeführt, damit man einfach den Interpret eines Albums feststellen kann. (Und nicht über die einzelnen Lieder bestimmen muss). Für Sampler wird ein extra Interpret "Sampler" in die Datenbank aufgenommen.

Diese war bisher meine "endgültige" Lösung. Aber aus den Aspekten, dass 2 (oder mehrere) Interpreten zusammen ein Lied spielen oder mehrere Interpreten unterschiedliche Versionen von Liedern spielen (Covers) sind nun noch die Versionen 2 und 3 entstanden. Bei dieser Version müsste ich ein Lied entweder mehrfach (für jeden einzelnen Interpret) erfassen oder die Interpret Kombination als einen einzigen (neuen) Interpreten erfassen (etwa "Interpret1 und Interpret2").

Version 2: http://home.arcor.de/crazy-x/musicfire/musicfire2.png

Hier kann sowohl ein Lied als auch ein Album von mehreren verschiedenen Interpreten stammen. Aber ich denke, je komplexer die DB wird desto komplexer wird auch später die Bedienung. Deshalb weis ich nicht so recht, ob diese Version wirklich besser ist, als die erste. Mögliche Probleme: Grenze zwischen einem gemeinsamen Album von Interpret1 und Interpret2 und einem Sampler? ...

Version 3: http://home.arcor.de/crazy-x/musicfire/musicfire3.png

Hier besteht schließlich noch die redundanzfreie Speicherung von Coverversionen. Die Tabelle Lied speichert hier den Titel und den Songtext eines Liedes und die Tabelle "Interpretation" führt die einzelnen Coverversionen davon auf. Falls eine Coverversion einen etwas anderen Liedtext hat, kann dieser in dem Attribut AbweichenderLiedtext gespeichert werden.

Allerdings ist *imho* der Vorteil dieser Version nicht groß genug um den notwendigen Mehraufwand zu rechtfertigen!?

Deshalb würde ich im Moment zwischen Version 1 und 2 tendieren. Was findet ihr besser? Version 2 und 2 habe ich leider nocht nicht getestet! Ich hoffe ihr könnt mir helfen und ein wenig Feedback geben.

Vielen Dank schonmal im voraus!

Crazy-X

entelechie

ich finde die 2.variante am besten mit der m:n zuordnung
von lied und interpret.
was ich jedoch an allen strukturen seltsam finde ist
die zirkuläre verbindung von lied,interpret,cd,album.
ich würde mir überlegen, ob ein album von einem interpret
ist, oder ob es vielleicht eine getrennte 'band' (oder sowas
in der art) geben sollte.
das löst auch das problem mit der redundanten speicherung des
interpreten in der album tabelle.

lösung 3 ist mir dann etwas überstrukturiert

Bei die beiden Tabellen Genre / SubGenre liegt es am Namen ja schon nahe Genre -> SubGenre -> Lied (alles 1:n) zu designen.

Beispiel:
Pop -> SynthiePop -> Enjoy the Silence

Crazy-X

Hi,

Diese zirkuläre Verbindung kommt deshalb zustande, weil ich versucht habe die DB "Fehl-Tollerant" zu entwerfen. Z.B. wenn ich nicht weis auf welchem Album ein bestimmtes Lied erscheint, kann ich trotzdem den Interpret zum Lied zuordnen. Bei Variante 2 muss ich das sogar, damit ich weis von welchem der mehreren Interpreten pro Album das Lied stammt.

Wenn ich die Verbindung zwischen Album und Interpret nicht hätte, hätte ich folgendes Problem: Wenn ich ein neues Album erfasse, kann ich den Interpret dazu nicht erfassen. Erst wenn ich dem Album Lieder zuweise, kann ich indirekt den Interpret feststellen.

Zum Thema Subgenre:

So wie trinityDB das meint, war das die Subgenre Tabelle gar nicht gedacht. Mit Subgenre wollte ich eine Einteilung z.B. nach LoveSong, PartyMusik, Chillout...
Allerdings habe ich mir auch schon gedacht die Subgenres durch Keywords zu den einzelnen Liedern zu ersetzen. D.h. die Tabelle Lied bekommt ein zusätzliches Attribut "Keywords", indem ich dann einfach die Keywords dazu reinschreibe. Z.B. "Lovesong, Rockballade, Saxofon" usw.

Diese Methode wäre vieleicht praktischer!?

TIA

Crazy-X

Crazy-X

Hi,

Zur Variante 2 ist mir noch folgendes Problem aufgefallen:

Wenn ich z.B. eine Liste mit allen Liedern anzeigen möchte, bekomme ich von meiner SQL Abfrage z.B. folgendes Ergebnis:

[b]Titel[/b]        [b]Interpret[/b]
Lied 1       InterpretA
Lied 1       InterpretB
Lied 2       InterpretC

D.h. soviele verschiedene Interpreter ein Lied hat, so oft wird es auch in der Liste aufgeführt. Somit muss ich die Liste vor dem Anzeigen erstnochmal programmtechnisch auseinander nehmen, damit jedes Lied nur einmal auftauch und die unterschiedlichen Interpreten zu den Liedern zusammenfassen.

Bei Variante 1 dagegen, würde ich pro Lied nur einen Interpreten angezeigt bekommen und somit taucht jedes Lied gleich beim Abfrageergebnis nur einmal auf.

Was denkt ihr dazu?

Hmm, so ein Datenbankentwurf ist schon eine schwere Entscheidung...

TIA
Crazy-X