Datenbankmodellierung

[StepByStep]

Zitat:

Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

>> Das finde ich auch, je mehr ich darüber nachdenke.

Ich stehe momentan wirklich auf dem Schlauch... Es ist mir erklärlich, weshalb ich alles in eine Tabelle packen sollte. Die würde dann ja irgendwie so aussehen:

Kategorie

ID

BookType

Costtype

Sub_Name

Main_Name

Parent

Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG

[mkinzler]

Zitat von StepByStep:

Zitat:

Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

Kategorie

ID

BookType

Costtype

Sub_Name

Main_Name

Parent

Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG

"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".

[StepByStep]

Zitat:

Wenn jetzt später ein neuer Belegtyp z.B. Bearbeitungslaufzettel benötigt wird musst du im 1. Fall das komplette Modell erweitern und auch das Programm anpassen; im 2. Fall wird einfach ein neuer Datensatz in 'ReceiptType' eingefügt.

>> Das ist mir schon klar. Beide Varianten gehen, die Wartbarkeit der Ersten ist natürlich höher, aber dafür hat man keine aufgeblähten Tabellen. Ich glaube das ist eine persönlich Ansicht darauf: Entweder höherer Wartungsaufwand und schlankere Tabellen oder eben andersrum. Kann das sein? Einen anderen signifikanten Unterschied gibt es ja nicht, bis auf eventuell noch Performance.

Zitat:

"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".

>> Aber ich lege doch alle drei Kategorietabellen übereinander und da es einen Namen in Sub und Main gibt, brauche ich beide doch wieder. Andernfalls würde es ja bedeuten, dass eine der beiden Tabellen entfällt. Und warum will ich kein Child? Innerhalb dieser drei Ebenen muss ich doch auch zurück referenzieren können.

LG

[mkinzler]

Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.

[StepByStep]

Zitat:

Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.

>> Damit hast du natürlich vollkommen recht... Ich glaube so langsam verstehe ich euch.

[Jumpy]

Was man evtl. überlegen könnte hinzuzunehmen wäre dann ein Feld für den Typ oder den Level (im Sinne der Tiefe in einer Baumstruktur). Dies ist nicht zwingend nötig, über die Parents läßt sich das auch ermitteln, aber es erleichtert einem ggf. die Abfragen.

[mkinzler]

Kann aber wieder zu Inkonsistenzen führen.