Hallo zusammen,
seit einiger Zeit bastele ich etwas mit PHP und MySQL. Für den Hausgebrauch reicht bisher auch ganz gut.
Jetzt gehts aber um Folgendes. Ein User macht per Webinterface einen neuen Eintrag in eine News-Datenbank. Nun soll er auch die Möglichkeit haben, Bilder hochzuladen. Die Links sowie Bildunterschriften zu den Bildern sollen in einer MySQL-Datenbank gespeichert werden.
Das Hochladen ist auch nicht das Problem. Ich stelle mir gerade eher die Frage wie ich die Datenbank(en?) aufbaue. Schließlich weiß ich im Voraus nicht, wieviele Bilder der User zu jedem Eintrag hochladen möchte.
Ich habe mir nun zwei Lösungswege überlegt, aber beide noch rein theoretisch. Keine Ahnung ob die überhaupt *sinnvoll* durchführbar sind.
1) In meiner "Hauptdatenbank" in der die News, Datum, Autor etc. stehen mache ich eine zusätzliche INT-Spalte. Wenn ein User nun ein Bild hochlädt wird der Link sowie die Beschreibung dazu in einer extra Tabelle gespeichert. Alle zusammengehörigen Bilder bekommen die gleiche "Referenznummer". Diese Referenznummer wiederum wird in der Haupttabelle in der zusätzlichen INT-Spalte gespeichert.
Bei der Ausgabe muss ich dann nur in der extra Tabelle die Einträge rausfiltern, die die passende Referenznummer haben.
Das erscheint mir aber sehr umständlich.
2) Ich könnte mir auch vorstellen, sämtliche Bildlinks mit in der Haupttabelle zu speichern. Wäre mir eigentlich lieber. Aber da habe ich dann eben das Problem, dass ich nicht weiß, wieviele Felder ich im Voraus anlegen soll.
Ich hoffe, ich konnte mich verständlich ausdrücken. Wie wird das denn sonst so gemacht? Kann mir da jemand ein paar Tipps geben?
Grüße,
Alsion
Homepage selbermachen 7.850 Themen, 35.593 Beiträge
Es gibt zwei gängige Fälle auf die man häufig bei Datenbankdesign trifft (generell gibt es noch mehrere, aber die sind komplexer):
Eine 1:1 Abbildung und eine 1:N Abbildung. Bei einer 1:1 Abbildung gehört zu jedem Element (Beitrag) genau 1 weiteres Element (z.B. Bild). Hier kann man beides in eine Tabelle packen, sofern keine anderen Gründe dagegen sprechen wie Speicherplatzoptimierung, Optimierung der Wartbarkeit, Übersichtlichkeit, Portabilität, Geschwindigkeitsoptimierung oder unterschiedliche Speicherformate.
Bei einer 1:N Abbildung kommt man eigentlich nie um eine Auftrennung in verschiedene Tabellen herum, ohne sich massive Probleme oder Einschränkungen einzuhandeln.
Also wie Borlander sagte: Eine extra Tabelle mit einer Eindeutigen Referenz, bestenfalls als Foreign Key und beim Erstellen in einer Transaktion zusammen gefasst um die Integrität zu gewährleisten.