MySQL Datenbankdesign

[DadyCool]

Hey,

ich habe mal ne Frage zum Datenbankdesign.

Und zwar möchte ich gerne folgendes darstellen:
---
Benutzer kann Artikel schreiben: z.B. Newsartikel
Benutzer kann zu 0..* Teams gehören

Ein Team kann 0..* Projekte haben

Ein Projekt kann wieder 0..* projektspezifische Artikel haben.
---

So habe ich mir das Design überlegt.


Ich bin mir nicht ganz sicher ob das so überhaupt möglich ist. *grübel*
Was sagt ihr?

Edit: Richtige Grafik hochgeladen

gruß
DadyCool

 

[theHacker]

Ein Projekt ist genau einem Team zugeordnet? Dann siehts gut aus

 

[ice-breaker]

ich habe beim Drüberschauen keinen Fehler in dem Modell gefunden.
Jedoch finde ich die Bennenung der Attribute (Spalten) ziemlich komisch, warum prefixt du die teilweise nochmal mit dem Namen der Entität (Tabelle) ?

 

[DadyCool]

@theHacker
genau, ein Projekt ist genau einem Team zugeordnet.

@ice-breaker
gute Frage Dachte es sieht schicker aus.

Andere Frage:
Wenn ich jetzt alle News haben möchte könnte man das nun so machen?

Select * From Artikel where user_id > 0 …

Würde es evt. sin machen, einen Typ bei Artikel hinzuzufügen, für denn Fall das man verschiedene Artikelarten hat. Und article_user_id und article_project_id entfernen und durch z.b. write_id zu ersetzen?

Und dann einfach

Select * From Artikel where user_typ = "news" …

 

[flaschenkind]

ich habe beim Drüberschauen keinen Fehler in dem Modell gefunden.
Jedoch finde ich die Bennenung der Attribute (Spalten) ziemlich komisch, warum prefixt du die teilweise nochmal mit dem Namen der Entität (Tabelle) ?

Dass es bei allen Spalten ist, finde ich auch komisch. Ich mache dies nur, wenn ich ein reserviertes Wort als Feldnamen nutzen will (und mir nichts besseres einfällt) und bei den IDs.
Dort finde ich es sehr praktisch, weil ich daran direkt erkenne, wozu ein Einträg gehört, wenn ich die ID in einer anderen Tabelle sehe. Man könnte natürlich auch einfach user statt user_id schreiben und in der User Tabelle ist es id, aber dadurch sieht man auch direkt, dass die id gemeint ist und nicht z.B. eine zufällige Zahl (dummes Beispiel )
Außerdem ermöglicht es bei Joins USING(user_id) zu nutzen.

 

[ice-breaker]

jup, da ist es sinnvoll, aber bei nem "user_password" ?

 

[flaschenkind]

jup, da ist es sinnvoll, aber bei nem "user_password" ?

Da nicht password ist ja nur als Funktion PASSWORD() reserviert, als Feldnamen kann man es problemlos verwenden.

 

[Snyke]

Was ich normalerweise mach ist folgendes:
Man stelle sich das ganze als Objekt vor (ich weiss, immer diese OOP People), alle Felder werden nicht mit prefix versehen, referenzen haben den tabellennamen als prefix, damit ist eigentlich immer klar von wo auf was referenziert wird, ohne dass man die liste der foreign keys zu durchsuchen