![]() |
Datenbank: egal • Version: egal • Zugriff über: egal
Baum in einer Tabelle speichern
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.nHKnoten2 UKnoten2.1usw. Wie wird dieses in Tabellen gespeichert? Vielen Dank für Eure Hilfen im Voraus |
AW: Baum in einer Tabelle speichern
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) |
AW: Baum in einer Tabelle speichern
Je nach DB unterstützt auch das DB System eine Baumstruktur. Am Beispiel MSSQL:
![]() 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. |
AW: Baum in einer Tabelle speichern
Darauf achten, dass die Verknüpfung zwischen den Dokumenten (ID, ID_PARENT, optional: POSITION) in einer separaten Tabelle angelegt wird.
|
AW: Baum in einer Tabelle speichern
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
Delphi-Quellcode:
oder
TreePath, ...
Delphi-Quellcode:
oder
TreeID, TreeParentID, ...
Delphi-Quellcode:
als Spalten
TreeID, TreeParentID, TreeOrder, ...
in die Tabelle oder in eine andere Tabelle, welche nur den Tree enthält. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz