Rezepte und Telefonbuch

[euromark]

Beide sind noch nicht online.. Besonders letzteres ist eine sehr mächtige Anwendung.. da gibts noch viel zu tun.

Ich wollte nur ma die (vereinfachten) ER-Modelle in den Raum werfen - und fragen, inwiefern ihr irgendwo
Verbesserungsvorschläge habt - oder evtl hab ich auch an der ein oder anderen Stelle was übersehen..

hier die Links zu den modellen:
http://dereuromark.de/public/ERModell_RezepteSammlung.jpg
http://dereuromark.de/public/ERModell_TelefonAdressbuch.jpg
Thx

[havanna]

Hallo ???,

auf den ersten Blick, und ohne das in der Tiefe betrachtet zu haben, fällt mir folgendes auf:

- beide Modelle sind sehr verwirrend abgebildet. Ich weiß nicht ob du über entsprechende Tools verfügst, aber da gibt es auch einiges im Internet, um Datenbankmodelle übersichtlich abzubilden.
- Bei deinem Telefonbuch ist mir aufgefallen, dass du Dinge unnötigerweise doppelt abbildest - z.B. Group. Versuche solche Kategorisierungen abstrakter abzubilden und durch eine zusätzliche Tabelle zu konkretisieren. Auf jeden Fall ist das eine 1:n Beziehung.
- Es mag ganz nett sein, HABTM als Begriff zu verwenden, aber ich würde mich (applikationsunabhängig) an die allgemeinübliche Beschreibung halten (1:1, 1:n, n:m).
- Überlege dir, was jeweils im Mittelpunkt steht. Mittelpunkte können durch Foreign-Keys verbunden werden (denke nicht zu cake-mässig).

Beispiel:
Mittelpunkt: Artikel
hat 1:n Konditionssätze (Preise)
hat 1:n Artikeltexte (Textart, Sprache)

(Mittelpunkt)Auftrag hat 1:n Positionen - Artikel(foreign Key)
Auftrag steht in Beziehung zur Rechnung (1:n - Fakturaplan (Teilzahlung))
Auftrag hat n Partner (Auftraggeber, Warenempfänger, Rechnungsempfänger, Regulierer, Vertriebsbeauftragter, Provisionsempfänger,...)

Wie ich das sehe, steckt das Modell noch sehr in den Anfängen

Mich wundert es sowieso, dass viele sich auf ein Schlüsselfeld in einer Tabelle beschränken. Es ist alles eine Frage der Definition. Professionelle Datenbanken (Oracle, MS-SQL, Interbase) unterstützen von Haus aus verknüpfte Schlüssel.
Denke nur mal du hast eine Tabelle Texte in denen du die Einträge mehrsprachig abbildest. Der Schlüssel (um am oberen Beispiel zu bleiben) könnte sein: Artikelnummer, Text-ID (damit meine ich nicht eine Zahl), Sprache. Nur mit diesem Schlüssel darf es keine doppelten Einträge geben.

Sorry, wenn das kleinkariert scheint. Aber ich komme aus der SAP-Welt. SAP hat mehr als 15.000 Tabellen und da ist kaum etwas überflüssig doppelt gemoppelt.

Ciao Thomas

[euromark]

Hi Thomas

prinzipiell ist HABTM als bezeichnung immernoch application-independant, da es
sich um eine allgemeine und äußert griffige bezeichnung handelt.
nichtsdestotrotz kann man natürlich wirklich bei den üblichen 1:n etc als Bezeichnungen bleiben.
das is wahr.

gruppen sind hier in der tat nicht ohne grund mit n:m modelliert - verstehe auch nicht, warum das 1:n sein sollte.
und doppelung sehe ich hier auch keine.

alle eingezeichneten HM-Beziehungen sind doch mit foreign keys gelöst (ohne eigenständige zwischentabelle),
lediglich die (deswegen auch rechteckig) n:m tables sind echte "zwischen-tabellen"

sicher sind SAP und solche kleinen anwendungen kaum zu vergleichen..
aber dennoch vielen dank für deine kritik.

mark

[havanna]

Hallo Mark,

du hast einmal "Groups" (allgemein) und einmal "Chat Groups" - oder sehe ich da was falsch?
Ich würde nur eine Tabelle allgemein user/groups machen, und in der Definition der Gruppen-Tabelle diese spezifizieren.

Dann hast du bei den phone numbers eine Beziehung zu numbers - was ist das? Wenn du damit den Country Code (+49, +41) abbilden möchtest, dann kannst du das auch in die country Tabelle tun. Den Area-Code kannst du auch mit in die Ländertabelle machen.

Sicher sind solche Anwendungen nicht zu vergleichen. Aber es geht ja um die Frage um ein sauberes und gutes Datenbankmodell - und da sitzen alle Anwendungen in einem Boot.

Ciao Thomas

[euromark]

dazu fehlt dir natürlich der hintergrund, warum dies 2 tabellen sind
es handelt sich hierbei nämlich um 2 absolut unterschiedliche inhalte - die auch nichts miteinander zu tun haben

das eine sind gruppen für user (groups), um sie z.b. alle unter "Skiausflug" zu gruppieren

das andere sind in sich hermetisch abgeschottete bereiche unter denen sich von dem besitzer des telefonbuchs quasi eingeladene gruppen-mitglieder unterhalten können. ne art studivz gruppe - nur ohne studivz
diese müssen nichts mit den vielen gruppen groups zu tun haben

die numbers sind unique
sprich, die ganze family (5 köpfig) hat mehrere PhoneNumbers, die wiederum alle auf die selbe "Number" zugreifen
wenn diese nun umziehen, haben sie mit 1 klick die adresse und telefonnummer geswitcht, redundanz wird hier soweit wie möglich vermieden (und probleme bei teilumzügen etc durch die applikation abgefangen)

trägt man als detail dann zu einer nummer "temporär vom netz/kaputt" ein, wirkt sich das logischerweise auf alle familienmitglieder aus, was ja auch sinn macht, da sie sich ja den anschluss teilen
und man es so nicht allen 5 redundant hinzufügen muss


jepp
und ich bin der meinung, dass mein ansatz der sauberste ist
aber bin gerne bereit, an der ein oder anderen stelle (wo es sinn macht) mich korrigieren zu lassen