Marc Reichelt: Sinnvollste Lösung für Datenbankproblem?

Hallo an alle,

ich arbeite derzeit an einer einfachen Webseite, wo alle möglichen Künstler URLs zu ihren offen lizenzierten Musikdateien eintragen können.

Jetzt habe ich die Datenbankstruktur schon das zweite Mal verworfen, und nun wieder ein neues Konzept - mein Problem dabei werde ich gleich schildern.
Da sich die Daten für die Künstler meist für alle Lieder gemeinsam ändern, habe ich zwei Tabellen entworfen - eine für die Künstler ('artists'), und eine für die Lieder ('songs').
Folgend der Tabellenentwurf für 'artists' (mir ist klar, dass die erwähnten Künstler ihre Musik bestimmt nicht unter offene Lizenzen stellen, sie dienen hier nur als Beispiel):

id | name            | url
-----------------------------------------------
1  | Die Toten Hosen | http://dth.de/
2  | Die Ärzte       | http://bademeister.com/
3  | Rammstein       | http://rammstein.de/

Folgend nun die Tabelle 'songs' (wegen der Darstellung bei kleinen Auflösungen etwas umgebrochen):

id | artist_id | license     | hits | name       | url                             | =>
------------------------------------------------------------------------------------ =>
1  | 1         | cc-by       | 234  | Was Zählt  | http://dth.de/waszaehlt.mp3     | =>
2  | 1         | cc-by-nc-nd | 123  | Bayern     | http://dth.de/bayern.mp3        | =>
3  | 1         | cc-by-nc-nd | 2    | Mehr Davon | http://dth.de/mehrdavon.mp3     | =>
4  | 2         | cc-by-nc    | 67   | Der Graf   | http://bademeister.com/graf.ogg | =>
5  | 3         | cc-by-nc-sa | 2035 | Seemann    | http://rammstein.de/seemann.mp3 | =>

filetype | admin_id | hash_md5 | filesize | length
---------------------------------------------------
mp3      | 2        | ...      | 3245100  | 205
mp3      | 2        | ...      | 4021030  | 215
mp3      | 1        | ...      | 3910341  | 195
ogg      | 3        | ...      | 4632157  | 243
mp3      | 5        | ...      | 2903470  | 315

Dabei ist 'artist_id' die entsprechende ID des Künstlers (artists.id), 'license' ist eine Abkürzung für die entsprechende Lizenz. 'hits' enthält die Anzahl der Zugriffe auf das einzelne Stück, 'name' und 'url' sollten denke ich klar sein. 'filetype' gibt den verwendeten Typ an, also derzeit entweder mp3 oder ogg (die URL muss ja nicht zwangsläufig auf dem Dateityp enden ;-).
'admin_id' ist die entsprechende ID des Admins, der diesen Musiktitel in die Datenbank eingetragen hat. Diese werden in einer Tabelle 'admins' gespeichert. 'has_md5' speichert die MD5-Prüfsumme, die eventuell später von einem eigens programmierten Robot in einem bestimmten Intervall (z.B. eine Woche) aktualisiert und überprüft wird - bei einer Änderung werden die Admins benachrichtigt. 'filesize' ist die Dateigröße in Bytes und 'length' die Länge des Stücks in Sekunden, das sind Infomationen die später eventuell auch vom Robot ermittelt werden und schließlich dem Endbenutzer nützlich sein können.

Uff.
Jetzt zu meinem eigentlichen Problem.

Da ein Künstler nur Vorschläge machen kann (Datenbank 'temp_songs'), die dann von einem Admin in die Datenbank eingetragen werden können, kann er selbst keine Einträge anlegen. Sobald ein Künstler in die Datenbank 'artists' eingetragen ist, ist das kein Problem mehr.

Dabei ist das Ganze auch eine Gewissensfrage, denn ich könnte die Tabelle 'artists' auch verwerfen und die Informationen direkt in die Tabelle 'songs' eintragen. Da würde sich das Problem von selbst beheben, da der Künstler nun stets einfach den Künstlernamen und die Homepage-URL mit angibt. Etwas mehr Speicherplatzverbrauch, aber wesentlich weniger Probleme und Komplexität.
Wenn ich ehrlich bin, glaube ich dass selbst eine Datenbankgröße von 10 MB nicht so schnell überschritten wird - und ich habe reichlich(tm) Speicherplatz.

Kann mir jemand bei meiner Entscheidung helfen? :-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

--
Linux is like a wigwam - no windows, no gates and an Apache inside!
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
http://emmanuel.dammerer.at/selfcode.html
  1. echo $begrüßung;

    Kann mir jemand bei meiner Entscheidung helfen? :-)

    . o O (  Hab ich da jetzt (wieder mal) die eigentliche Frage überlesen?  )

    Wenn die neuen, oder auch die alten neuen Künstler sich sowieso in temp_song eintragen und du dann den Eintrag per Hand in die richtigen Tabellen übernimmst (bzw. dessen Übernahme anstößt), sähe ich da kein Problem, ein Formular zu gestalten, das die Songdaten anzeigt, eine Auswahlmöglichkeit für einen artists-Datensatz und Eingabefelder für neue artist-Daten.
    Die rückwärtige Programmlogik nimmt dann die Songdaten und wenn kein artist-Datensatz gewählt ist, legt sie vorher einen neuen mit den Daten aus den Eingabefeldern an. Ansonsten werden letztere ignoriert und stattdessen die artist_id aus der Auswahl genommen.

    Das Prinzip könnte man auch für die temp_songs verwenden. Auswahlmöglichkeit und Neueingabe-Felder gleichzeitig anzeigen und einen Hinweis dazu, dass entweder das eine oder das andere verwendet werden soll.

    echo "$verabschiedung $name";

    1. Hallo dedlfix,

      Wenn die neuen, oder auch die alten neuen Künstler sich sowieso in temp_song eintragen und du dann den Eintrag per Hand in die richtigen Tabellen übernimmst (bzw. dessen Übernahme anstößt), sähe ich da kein Problem, ein Formular zu gestalten, das die Songdaten anzeigt, eine Auswahlmöglichkeit für einen artists-Datensatz und Eingabefelder für neue artist-Daten.
      Die rückwärtige Programmlogik nimmt dann die Songdaten und wenn kein artist-Datensatz gewählt ist, legt sie vorher einen neuen mit den Daten aus den Eingabefeldern an. Ansonsten werden letztere ignoriert und stattdessen die artist_id aus der Auswahl genommen.

      Bei meinem aktuellem Entwurf mache ich es fast genauso:
      1. Der Benutzer kann wählen zwischen einem existierenden Künstler oder einem neuen Künstler.
      2.1. Wurde ein existierender Künstler ausgewählt, so kann man diesem ganz einfach ein Stück hinzufügen.
      2.2. Wurde "neuer Künstler" ausgewählt, so werden im zweiten Schritt noch zwei zusätzliche Felder angezeigt, nämlich für den Namen und die Homepage des Künstlers.
      3. Wurde in Schritt 2 ein existierender Künstler asgewählt - kein Problem. Wenn doch, so wird er derzeit einfach angelegt.

      Ich habe halt nur irgendwie das Gefühl, dass ich hier mit zwei Tabellen ('artists' und 'songs') mit Kanonen auf Spatzen schieße, da es mit einer Tabelle wesentlich weniger Aufwand bedeuten würde.

      Grüße

      Marc Reichelt || http://www.marcreichelt.de/

      --
      Linux is like a wigwam - no windows, no gates and an Apache inside!
      Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
      http://emmanuel.dammerer.at/selfcode.html
      1. echo $begrüßung;

        Ich habe halt nur irgendwie das Gefühl, dass ich hier mit zwei Tabellen ('artists' und 'songs') mit Kanonen auf Spatzen schieße, da es mit einer Tabelle wesentlich weniger Aufwand bedeuten würde.

        Dieses Gefühl kannst du nur mit genügend Erfahrung unterdrücken :-) Empfehlungen von Außenstehenden können da auch nur Anhaltspunkte geben, da nur du weißt, was später vielleicht mal noch für Informationen zum Artist gespeichert werden sollen. Und je mehr das werden, desto schneller rechnet sich dann der Aufwand einer zweiten Tabelle, sonst müsstest du diese Informationen ja dann bei Änderungen für jedem Eintrag unter songs aktualisieren.

        Das Script zu schreiben ist ein mehr oder weniger einmaliger Akt. Datenpflege kommt später noch häufiger vor. Das im Hinterkopf sollte die Entscheidung zum Platzieren des Aufwandes auch noch mal erleichtern.

        echo "$verabschiedung $name";

    2. Hallo nochmals dedlfix,

      Wenn die neuen, oder auch die alten neuen Künstler sich sowieso in temp_song eintragen und du dann den Eintrag per Hand in die richtigen Tabellen übernimmst (bzw. dessen Übernahme anstößt), sähe ich da kein Problem, ein Formular zu gestalten, das die Songdaten anzeigt, eine Auswahlmöglichkeit für einen artists-Datensatz und Eingabefelder für neue artist-Daten.
      Die rückwärtige Programmlogik nimmt dann die Songdaten und wenn kein artist-Datensatz gewählt ist, legt sie vorher einen neuen mit den Daten aus den Eingabefeldern an. Ansonsten werden letztere ignoriert und stattdessen die artist_id aus der Auswahl genommen.

      Jetzt habe ich es begriffen.
      Da war so ein riesiges Brett vor meinem Kopf, das ist jetzt weg. :-D

      Die Lösung ist gar nicht so schwer. Wenn ein Künstler gerade erst einen neuen Eintrag tätigt, und dann anschließend noch einen weiteren (ohne dass der Künstler bereits in die feste Datenbank übernommen ist), so muss er die Angaben für Künstlername und -homepage halt nochmals machen. Aber das kann man auch noch ein wenig automatisieren...
      :-)

      Grüße und vielen Dank

      Marc Reichelt || http://www.marcreichelt.de/

      --
      Linux is like a wigwam - no windows, no gates and an Apache inside!
      Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
      http://emmanuel.dammerer.at/selfcode.html