# Baumstruktur in Tabellen - Allgemeines Vorgehen und Probleme



## shutdown (7. November 2007)

Hallo an alle!

Ich möchte mal eine kleine Diskussion starten, wie ihr so eine Baumstruktur in einer Datenbank-Tabelle abbildet, auf was für Probleme ihr stoßt und wie ihr sie gelöst habt.

Es gibt zwar schon ein paar Threads, wie man konkret eine solche Struktur abbilden kann, allerdings sind das immer nur ein paar schnelle Problemlösungen, die sich mit dem Problem an sich nicht so richtig auseinander setzen.

Es gibt ja das Standard-Vorgehen, dass man nur eine Tabelle verwendet, in der ein Eintrag für einen Knoten steht und dieser Knoten enthält die Referenz auf sein Eltern-Objekt:
ID|Name|Parent
1|Großvater|NULL
2|Vater|1
3|Kind|2
4|Enkel|3

(Ich bitte die geschlechts-betonte Benennung zu entschuldigen)

Vorteile:
- Im Prinzip ist eine unendlich tiefe Verschachtelung möglich
- alles bleibt in einer Tabelle
- einfache Verarbeitung mittels rekursiver Algorithmen möglich

Die Nachteile sind folgende:
- Um eine Baumstruktur außerhalb der Datenbank rekursiv darstellen zu können, muss die gesamte Tabelle auf einmal geladen werden, da anders ja evtl. Beziehungen verloren gehen.
- Will man nicht den gesamten Baum auf einmal laden (also nur einen Ast laden), muss man die Tabelle mehrfach auf sich selbst joinen. Dadurch geht die unendliche Verschachtelungs-Tiefe verloren, weil sie durch die Anzahl der Self-Joins begrenzt wird.

Mögliche Lösungswege:
- Man setzt getrennte Selects für jede Ebene ab, die man darstellen möchte (jeweils versehen mit der jeweils gewünschten Parent-Id). Auch das ist nicht wirklich schön, kann allerdings bei entsprechender Algorithmik die unbegrenzte Verschachtelungstiefe erhalten.


Also, ich hoffe ihr versteht, worauf ich mit dieser Diskussion hinaus möchte. Ich möchte gerne eure Meinungen zu diesem vielleicht etwas theoretischen Thema hören.
Und ich denke, das wird vielen, die sich mit diesem Thema neu beschäftigen wollen, eine Hilfe sein.

Gruß
shutdown


----------



## olqs (7. November 2007)

Das Problem hatte ich letztens bei dem Versuch ein HTML Navigationsmenu in der DB abzulegen auch.

Da mir die Möglichkeit mit den Joins nicht gefiel, da man ja nicht weis wieviele Ebenen abgespeichert wurden, hab ich mich entschieden die Logik ins PHP Frontend zu verlagen und da, wie schon als Möglichkeit angegeben, rekursiv Ebene für Ebene durchzugehen.

Mal dazu die Vor- und Nachteile:

Vorteile:
- ziemlich kompakter Code 
- und ein "selbstdurchlaufen des Baums"
Nachteile sind:
- kein direkter Zugriff auf einen Ast möglich ist
- bei einem Query der die ganze Tabelle ausliest, muss die Strukturierung der Daten in der Applikation erfolgen.



Falls der php Code interessiert und n Web Beispiel gewünscht wird, kann ich das ja noch posten. Ist bei uns ne Anwendung im Intranet.


----------

