Baum in einer Tabelle speichern

[NoName1]

Guten Tag Forumsleser,
ich möchte Dokumente in einer Tabelle speichern. Da die Dokumente in verschiedene Ordnungsgruppen eingeteilt sind, bietet sich hierfür eine Baumstruktur an. So eine Baumstruktur habe ich noch nicht angelegt. Die Tiefe des Baumes soll nicht begrenzt sein.
Meine Fragen: Wieviele Tabellen werden benötigt und wie ist der Aufbau dieser Tabellen?

Ich stelle mir die Struktur in etwa so vor:
HKnoten1

UKnoten1.1
UKnoten1.2
...

UKnoten1.n
UKnoten1.n.1
---
UKnoten1.n.n

HKnoten2

UKnoten2.1
UKnoten2.n

usw.

Wie wird dieses in Tabellen gespeichert?

Vielen Dank für Eure Hilfen im Voraus

[himitsu]

Na meistnes hat man einfach eine Parent-Spalte, wo man den jeweiligen übergeordneten HKnoten1, HKnoten2 und UKnoten1.n verlinkt und leer, wenn es selber die Rootknoten HKnoten1 und HKnoten2 sind.

Meistens aber nicht direkt auf den "Text", falls er mal leer oder doppelt ist, sondern gegen eine ID (z.B. blind durchnummeriert oder ein Timestamp oder eine sprechende ID)


Und passend dazu nutzen gute Grid-/Tree-Komponenten genau das selbe Model.




[add]
Statt des Parent kann man auch den kompletten Pfad speichern, siehe das MSSQL,
oder bei einer Liste von Dateinamen, inkl. Pfad.




Alternativ kann man natürlich auch einfach alle Zeilen in fester Reihenfolge speichern
und jeweils das Level der Einrückung dazu. (wenn diese Werte stimmig sind, ergibt sich ein schöner Tree)

[TigerLilly]

Je nach DB unterstützt auch das DB System eine Baumstruktur. Am Beispiel MSSQL:
https://learn.microsoft.com/en-us/sq...l-server-ver16

Stichwort: Hierarchische Daten

Und: Bäume können recht komplex sein. Ein Knoten kann mehrere Unterknoten haben, aber er kann auch mehrere Oberknoten haben. Der Baum muss nicht insgesamt zusammenhängend sein.

[Blup]

Darauf achten, dass die Verknüpfung zwischen den Dokumenten (ID, ID_PARENT, optional: POSITION) in einer separaten Tabelle angelegt wird.

[himitsu]

Ob in der Tabelle selber oder der Baum in einer eigenen Tabelle, welche auf Erstere verlinkt, ist per se erstmal egal, in Bezug auf das "Wie".

Ja, Position, um eine alternative Sortierung innrhalb der Knoten zu bekommen, kann nicht schaden ... falls es keine passende Sortierung z.B. nach "Name" gibt. (und auch unnötig bei dem MSSQL)

siehe MSSQL: eine blinde Durchnummerierung mag ich nicht wirklich.
Will ist da einen Knoten verschieben/einfügen, dann muß ich eventuell auch alle Pfade der Nachfolgenden umschreiben.

Wird der ganze Pfad, gegenüber nur dem Parent gespeichert, dann müssen beim Verschieben/Umgenennen eines Knotens auch die Pfade aller Unterknoten ändern.

Und außerdem sind das doch "nutzlos" doppete Daten




also TreePath, ... oder TreeID, TreeParentID, ... oder TreeID, TreeParentID, TreeOrder, ... als Spalten
in die Tabelle oder in eine andere Tabelle, welche nur den Tree enthält.