Datenbankmodellierung

[StepByStep]

Das ist wohl richtig, aber das sind im Regelfall doch auch Daten, die sich eben nicht weiter Normalisieren lassen.

[mkinzler]

Wenn Du mehrere Tabellen für das gleiche anlegst würde ich auch nicht von Normalisierung reden. Kaetegorien sind Kategorien, ob sie nun Haupt- oder Unterkategorien sind.

[StepByStep]

Ich hatte auch mehr etwas im Kopf wie: Auftrag (Hauptkategorie), Auftragsposition (Kategorie), Auftragsunterposition (Unterkategorie). So wäre es nach seinem Beispiel, zumindest für mich.

[mkinzler]

Auftragspositionen und Auftragsunterpositionen sind eigentlich das gleiche, der Fremdschlüssel steuert dies ja.
Aufträge sind natürlich etwas komplett anderes.

Ich würde eher eine Tabelle für Aufträge, Lieferscheine, Rechnungen usw. verwenden und eine für die Positionen.

[StepByStep]

Hm... ich finde den Ansatz wirklich interessant. Nun kenne ich auch noch nicht so viele... Bei uns haben wir das alles ausgelagert in eigene Tabellen, um eben alles zu trennen. Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt. Und darauf dann einen Index... Klar geht das, aber habe noch nicht so ganz verstanden warum? Was macht das "besser" als es zu trennen, bzw. zu normalisieren?

Aber wir driften auch weiter vom Ursprungsthema ab.

LG

[jobo]

Zitat:

Zitat von StepByStep (Beitrag 1399101)

Aber wir driften auch weiter vom Ursprungsthema ab.

Bei einer Modellierungsfrage finde ich die Diskussion hier nicht wirklich abgedriftet.
Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

Ich sehe das so wie mkinzler und codehunter, ein Parentverweis für eine hierarchische Kategorisierung ist idR naheliegend und kein Normalformverstoß. Selbst wenn er das wäre, sowas wäre auch nicht selten und m.E. nicht per se strafbar. Frage wäre immer, welche Vor und Nachteile aus bestimmten Verfahren entstehen.
10 Tabellen für verschiedene Ebenen halte ich dagegen schon für fragwürdig.
Wer oder was auch immer einen solchen Kategorieverweis bei sich trägt, ist per Model darauf festgenagelt. Also quasi wie in einem Kastensystem, frühstens nach Tod und Wiedergeburt gibt's einen anderen Level. Nicht sehr flexibel.

Was die Performanceaspekte angeht:
Performanceprobleme kann es immer geben, natürlich gern wenn Tabellen sehr groß werden. In solchen Fällen kann man über Denormalisierung nachdenken, aber immer zuletzt. Gute Indizierung, geeignete Datenbanken mit smarter Implementierung und intelligenter Abfragesyntax wären da für mich naheliegender.

[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:

Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt.

Eigene Tabelle und FK in Tabelle für die Belege.

Zitat:

Was macht das "besser" als es zu trennen, bzw. zu normalisieren?

Es ist flexibler.

Und Warum sollte eine System mit den Tabellen
'Order', 'DeliveryNote', 'Invoice', ..., 'OrderPosition', 'DeliveryPosition', 'InvoicePosition', ...

normalisierter sein als ein System mit den Tabellen 'ReceiptType', 'Receipe', 'Position'?

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.

[mkinzler]

Zitat:

Zitat von StepByStep (Beitrag 1399109)

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