mysql-Datenbankentwurf: Euren Senf dazu...

[besi]

Hallo Zusammen. Ich möchte eine Seite erstellen, wo Benützer eigene Fotos hochladen können. Die Fotos verfügen dann über einen Besitzer, Kommentare, Beschreibung, Adresse (Adresse, PLZ, Ort), und eine Kategorie.

Ich habe mir nun eine Datenstruktur überlegt. Damit das ganze System flexibel bleibt, soll das DB-System relational sein. Ich habe also folgende Tabellen:

Mit targettype gibt man an zu welchem Typ das jeweilige Element zugeordnet werden soll (z.B. Ein Comment zu einem Bild oder umgekehrt) mit Targetid wird das entsprechende Objekt genau identifiziert. So kann man z.B. mit der Tabelle 'kat' Unterkategorien erstellen und man kann eigentlich jedes Element einem anderen zuordnen


Kat:
- id
- targettype
- targetid
- name

User:
- id
- targettype
- targetid
- kat (Kategorie "admin" , "redakteur", ...)
- username
- email
- pw (Passwort in md5)
- adressid (gibt die Adresse an)

Guestbook
- id
- targettype
- targetid
- email
- url
- subject
- text
- date


Picture:
- id
- targettype
- targetid
- path (Gibt den Pfad des Bildes an)
- date

Comment:
- id
- targettype (Gibt an zu was für einem Typ Beitrag der Kommentar gehört z.B. "picture")
- targetid (Gibt die id des entsprechenden Beitrags an)
- date

Adresse:
- id
- targettype
- targetid
- strasse
- plz
- ort


Da ich noch nicht viele solcher Datenbankprojekte hinter mir habe und ich möchte, dass das System später leicht zu erweitern ist. Bitte ich euch euren "Senf" dazuzugeben, was man vielleicht verbessern oder optimieren könnte. Ich bin für alle Anregungen sehr dankbar!

 

[elninio]

Hallo,

ich verstehe einige Sachen nicht, es kann allerdings sein, dass sie so gewollt sind. z.B. Speicherst du bei einem Kommentar TargetType (wieso? Ist doch klar das es ein Kommentar ist), ausserdem Email und URL (ich geh mal davon aus, dass man nur Kommentare schreiben darf, wenn man registriert ist, das geht aus deinem Text allerdings nicht hervor - dann entfällt somit die Email. Statt URL ist es ausserdem bei Texten auch sinnvoll, im Gegensatz zu Bildern, diese direkt in der Datenbank zu speichern. Ist auch üblich so. Andererseits hast du wieder ein Feld "Text" - Also ich denke, es reicht entweder den Text oder die URL wo der Text steht zu speichern, aber beides nicht, oder meinst du mit URL die Homepage des "Kommentarschreibers" Wäre für mich wieder unlogisch, weil warum speicherst du von den Kommentatoren die URLs, aber nicht von den Benutzern, die Bilder hochladen...) Dann verwendest du noch Subject - weiss ich nicht ob man das bei Kommentaren braucht, in meiner von dir unabhängigen Lösung hab ichs nicht eingebaut - ist aber auch sicher nicht falsch.

Naja hier meine Lösung: (Das mit dem TargetType denke ich nicht dass man das unbedingt braucht, man sieht ja auch so anhand der Tabelle was zu was gehört.)

Foto:
- id (primary key)
- userID (foreign key)
- url (wo das Foto hochgeladen ist)

User:
- mail (primary key)
- password
- street
- plz
- city
- username
- catID (foreign key)

Comment:
- userID (primary key)
- fotoID (primary key)
- text
- date
- evtl. subject, wenn du meinst es zu brauchen

Category
- id (primary key)
- name
- url (für Logo von der Kategorie)

Der Datenbankentwurf wurde nach folgendem Schema erstellt:
Ein Benutzer hat null bis mehrere Fotos
Ein Foto gehört genau einem Benutzer
Ein Kommentar gehört genau einem Benutzer
Ein Benutzer hat null bis mehrere Kommentare
Ein Benutzer ist zugeordnet zu genau einer Kategorie
Eine Kategorie ist zugeodrnet zu null bis mehreren Benutzern

(Du musst die Sätze genau überprüfen, wenn einer davon bei dir nicht richtig ist, ist mein Entwurf möglicherweise falsch)

Mal so ne ganz allgemeine Sache: Ich sehe immer wieder, wie Leute jeder Tabelle eine ID zuordnen, obwohl das absolut nicht nötig ist. Macht euch doch nicht mehr Arbeit, als ihr müsst! Wenn andere Schlüsselkandidaten sich als eindeutig herausstellen, dann braucht ihr doch nicht noch ne ID einführen.

Hoffe geholfen zu haben

edit: Seh grade, du hast Adresse als eigene Tabelle gemacht. Das macht nur Sinn, wenn du einem Benutzer mehrere Adressen zuweisen willst - oder wenn du erlaubst, dass die Adresse leer ist. Wenn ein Benutzer immer genau eine Adresse hat, hast du eine 1 zu 1 muss - Beziehung, die du in einer Tabelle zusammenschreiben kannst.

 

[besi]

@elninio: Danke zuerst ein mal für deine Ausführungen. Das mit targettype und targetid mache ich deswegen, weil ich mir gut vorstellen kann, das ganze auszubauen...
Ich habe dann folgende typen
- Bild
- User
- Kommentar
- Newsbeitrag
- Guestbookeintrag
- Artikel
- Kategorien

Jetzt ist es ja denkbar dass ich einem User ein Bild (oder mehrere zuweisen will). Oder dass ich ein Bild einem Newseintrag zuweise. Dann würde zum Beispiel im Newsbeitrag stehen "Bilder zu diesem Thema hier klicken". Oder dass ich Kommentare einem Bild, Gästebucheintrag usw. zuweisen kann.

So kann ich eigentlich alle Elemente einander zuweisen. So kann ich dann auch Unterkategorien anlegen, indem ich eine "Kategorie" einer weiteren Kategorie zuordne.

Ich denke dass ich mit diesem System ziemlich flexible sachen machen kann. Wobei es sicherlich Kombinationen gibt die nicht viel Sinn machen. Wenn ich z.B. ein Newsbeitrag einem anderen Newsbeitrag zuordne.

Ist diese "Architektur" eher unprofessionell? Oder würde man das in der Praxis nicht mit einem solchen "Wirr Warr" lösen?

Dann noch ne Frage: Soweit ich weiss klappt das mit den foreign-keys beim Tabellentyp MyISAM nicht. Soll ich nun einen anderen Typ verwenden oder laufe ich dann Gefahr dass ich andere, wichtige Features dann nicht mehr habe?

 

[elninio]

Hmm also ob das in der Praxis so umgesetzt wird wie du es gemacht hast, kann ich dir leider nicht sagen, kenne Datenbanken bisher auch nur vom Studium. Da programmieren wir aber auf ner Oracle Datenbank, da gab es bisher keine Probleme mit Fremdschlüsseln. Wie es bei MySQL ist kann ich dir leider nicht sagen.

Bei meiner Lösung war es halt so gedacht, dass jeder Benutzer mehrere Bilder hochladen kann und selbst (Benutzer) in einer Benutzergruppe (admin, guest usw) ist. Zu jedem Bild könnte man Kommentare schreiben, wenn man als Benutzer registriert ist. Dein Modell ist viel flexiebler, das ist mir klar, aber ob es so funktioniert, weiss ich nicht... aber sicher gibts hier ja noch andere Leute die dir da mehr helfen können.

 

[besi]

Ich denke möglich ist alles. Ich kann aber schlecht beurteilen ob das System noch mögliche Hindernisse birgt...