Datenbankmodellierung

[mkinzler]

Und bei 10 Hierarchie-Ebenen dann 10 Tabellen?
Ich würde es auch mit einet Tabelle lösen.

[StepByStep]

Ja, bei 10 Hierarchie-Ebenen dann 10 Tabellen. Es ist doch auch in Bezug auf Abfragen viel effizienter/performanter schmalere Tabellen zu haben, statt einer riesigen, mal davon ab, dass man somit keine Normalisierung erreicht. Aber eben diese sollte man doch anstreben oder irre ich mich?

Die Berufsschule ist knapp ein Jahr her, aber ich bin ziemlich sicher, dass das dort vermittelt wird und überall sonst auch angestrebt wird.

LG

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1399067)

Und bei 10 Hierarchie-Ebenen dann 10 Tabellen?
Ich würde es auch mit einet Tabelle lösen.

Kommt ja immer auf den konkreten Fall an. Mir sagt halt meine praktische Erfahrung, dass starre hierarchische Strukturen von den meisten Anwendern als negativ empfunden werden. Man stelle sich einen Webshop vor, der eine starre Verzweigungstiefe hätte. In manchen Kategorien lägen dann Berge von Artikeln, in anderen nur einer oder zwei. Wenn die Kategorien funktional identisch und ihre Unterschiede über Attribute darstellbar sind, würde ich sie in einer Tabelle unterbringen, wie vormals geschrieben. Unterscheiden sie sich jedoch funktional stark und gibt es keine sinnvolle abweichende Verzweigungstiefe, dann kann man das auch mit drei Tabellen lösen.

EDIT/Nachtrag:

Zitat:

Zitat von StepByStep (Beitrag 1399070)

Ja, bei 10 Hierarchie-Ebenen dann 10 Tabellen. Es ist doch auch in Bezug auf Abfragen viel effizienter/performanter schmalere Tabellen zu haben, statt einer riesigen, mal davon ab, dass man somit keine Normalisierung erreicht. Aber eben diese sollte man doch anstreben oder irre ich mich?

Die Berufsschule ist knapp ein Jahr her, aber ich bin ziemlich sicher, dass das dort vermittelt wird und überall sonst auch angestrebt wird.

Theorie und Praxis eben. Kann der Anwender Kategoriestrukturen dynamisch selbst erstellen, deshalb mein Beispiel Webshop, dann müsstest du auch die Tabellen dynamisch erstellen. Das wird IMHO recht aufwendig und fehleranfällig, spätestens bei Programmupdates.

[mkinzler]

Oder in einer. Da ja die Hierarchie Teil der Tabelle ist. Im Nornallfall unterscheiden sich die Metadaten der Haupt-/Unter-/Unter-Unterkategorien ja nicht. Die oberste Ebene hat dann halt keine Parent.

[StepByStep]

Zitat:

Die oberste Ebene hat dann halt keine Parent.

>> Dann hast du eine Spalte die nur in 2 von 3 Fällen gefüllt ist? Ist das konsistent?

EDIT:

Zitat:

deshalb mein Beispiel Webshop

Aber in deinem Beispiel wäre es sowieso sinnvoller eine Artikeltabelle zu erstellen und darin eine Referenzspalte zu Kategorien einzubauen.

[Codehunter]

Zumal im Bereich von Buchhaltung und Warenwirtschaften die GoBD sowieso die Normalisierung ein Stück weit gekillt hat :roll:

@StepByStep: Bzgl. Normalisierung und Performance, da kann der Schuss auch nach hinten los gehen. Ich empfehle die letzten beiden Absätze auf dieser Seite.

EDIT:

Zitat:

Zitat von StepByStep (Beitrag 1399078)

Zitat:

deshalb mein Beispiel Webshop

Aber in deinem Beispiel wäre es sowieso sinnvoller eine Artikeltabelle zu erstellen und darin eine Referenzspalte zu Kategorien einzubauen.

Also bitte.... Wo ist denn da die dritte Normalform? 8-) Da wird bei den Artikeln eine Artikelnummer, bei den Kategorien eine Kategorienummer und dann in einer Verknüpfungstabelle beides zusammen geführt. Nur so kannst du einen Artikel in mehrere Kategorien legen.

[mkinzler]

Warum nicht. Ist bei den anderen Tabellen gibt es ja auch hin und wieder Felder die nicht gefüllt sind.
So wäre es auch einfacher aus einer Haupt- eine Subkategorie zu machen oder umgekehrt oder die übergeordnete zu ändern.

[mkinzler]

Ich sehe auch nicht, warum dies der Normalisierung widersprechen sollte. Diese fordert ja nur eine Abhängigkeit von den Nichtschlüsselfeldern vom (Primär)Schlüssel. ParentID ist ja aber ein (Fremd-)schlüssel.

[StepByStep]

Zitat:

Also bitte.... Wo ist denn da die dritte Normalform? Da wird bei den Artikeln eine Artikelnummer, bei den Kategorien eine Kategorienummer und dann in einer Verknüpfungstabelle beides zusammen geführt. Nur so kannst du einen Artikel in mehrere Kategorien legen.

>> Verzeih, da hast du natürlich vollkommen Recht! Mein Fehler. :oops:

Zitat:

Zudem verlangsamt es die Abfragegeschwindigkeit, da die Tabellen erst mithilfe von Joins verknüpft werden müssen

>> Also ich möchte meinen, dass Joins über Tabellen schneller gehen, als ein Select über eine Tabelle mit etlichen Massendaten. Vor allem wenn du dann noch sinnvolle Indizes angelegt hast.

Zitat:

Warum nicht. Ist bei den anderen Tabellen gibt es ja auch hin und wieder Felder die nicht gefüllt sind.
So wäre es auch einfacher aus einer Haupt- eine Subkategorie zu machen oder umgekehrt oder die übergeordnete zu ändern.

>> Mag sein, aber du hättest dann eine riesige Tabelle mit zig Daten. Das kann doch nicht gut sein. Und durch eine Tabelle trennst du ja nicht Nicht-Schlüsselfelder. Dann hättest du Name für Subkategorien und Name für Hauptkategorien...

LG

[mkinzler]

Zitat:

>> Also ich möchte meinen, dass Joins über Tabellen schneller gehen, als ein Select über eine Tabelle mit etlichen Massendaten. Vor allem wenn du dann noch sinnvolle Indizes angelegt hast.

Joins ist Joins, ob nun verschiedene Tabellen oder mehfach die selbe gejoint wird. Ausserdem ist ja die Frage, warum überhaupt gejoint werden muss.

Zitat:

>> Mag sein, aber du hättest dann eine riesige Tabelle mit zig Daten. Das kann doch nicht gut sein. Und durch eine Tabelle trennst du ja nicht Nicht-Schlüsselfelder. Dann hättest du Name für Subkategorien und Name für Hauptkategorien...

Ist das bei einer Adressen- oder Rechnungspositionentabelle anders? Da hat man auch viele verschiedene Daten beinhalten.