DB-Verknüpfungen untergeordneter Tree-Nodes anzeigen

[Pfoto]

Hallo!

Gibt es eine bewährte Lösung für folgendes Problem?

Ein Treeview soll in meinem Fall eine Art Kategorienliste darstellen.
Einen Datenbankeintrag kann man von einer Liste per Drag & Drop auf einen Node ziehen.
Intern wird dann in einer n:n-Tabelle die ID des Nodes und die ID des DB-Eintrags aufgenommen. Das funktioniert auch.
Was ist jedoch, wenn ich auf den Root des Nodes klicke und alle untergeordeten Einträge anzeigen lassen will?
Alle rekursiv durchlaufen und in ein SELECT-Statement einbauen würde dieses sehr aufblähen und langsam machen.
Ist in diesem Fall meine Überlegung richtig, bei der Verknüpfung mit einem Node auch automatisch Verknüpfungen mit den übergeordneten Nodes anzulegen.

Beispiel:
http://home.arcor.de/sinnspruch/NodeDemo.jpg
Ich verknüpfe meinen Eintrag mit Node 1.2.1
Intern legt das Programm auch Verknüpfungen mit Node 1.2 und Node 1 an.

Der Nachteil ist: Sobald ich einen Eintrag aus Node 1.2.1 lösche, muss ich auch dafür sorgen, dass aus allen übergeordneten Nodes der Eintrag verschwindet. Das macht die Sache bestimmt fehleranfälliger, oder?

Ich hatte auch schon die Version im Kopf, dass statt einer klassischen ID-Nummer die ganze Kombination, also im Beispiel "#1.2.1" gespeichert wird.
Bei einem Klick auf das Eltern-Node, würde dann nach "#1" gesucht werden, was ja auch automatisch "#1.2.2" finden würde. Ein nachträgliches Verschieben eines Nodes wäre aber so ziemlich unmöglich, da sich ja auch die ID ändern müsste (die möglicherweise ja schon verknüpft ist...)
Also irgendwie komme ich da auf keinen grünen Zweig.

Gibt es da überhaupt ein Patentrezept, das sich in der Praxis bereits bewährt ist?

Würde mich über eure Meinungen freuen


Gruß
Pfoto

[marabu]

Hallo Pfoto,

Zitat:

Zitat von pfoto

Intern wird dann in einer n:n-Tabelle die ID des Nodes und die ID des DB-Eintrags aufgenommen.

Nur zur Begriffsbestimmung - durch die von dir erwähnte m:n Beziehung stellen die Knoten der Baumansicht ein Klassifikationsschema dar. Bei einer 1:n Beziehung zwischen den Knoten und deinen Datensätzen würden wir von einer Gliederung sprechen. Der Unterschied im physischen Datenmodell liegt in der Einführung eines Beziehungsdatentyps. Beschränken wir die Betrachtung vorerst auf Gliederungen.

Gliederungsbäume sind essentiell hierarchische Strukturen und können in relationalen Datenbanken nur als selbstrekursive Tabelle umgesetzt werden. Für die weitere Diskussion führe ich die Tabelle OUTLINE (ID, POSITION, TITLE, OUTLINE_ID, ROOT_ID) zur Aufnahme von Gliederungsbäumen ein. Bei Speicherung nur eines einzigen Baumes würde das Attribut ROOT_ID nicht benötigt. ID ist Primärschlüssel, OUTLINE_ID und ROOT_ID sind "Fremdschlüssel" und referenzieren die eigene Tabelle, TITLE ist der Text für den Gliederungseintrag und POSITION die ab 0 gezählte Ordnungsnummer des Eintrages.

Schon beim Füllen des Baumes musst du dich entscheiden - alles auf einmal rein schaffen oder nur was nötig ist? Ich halte in der Regel eine vollständige Gliederung in einer Query offen:

SQL-Code:

SELECT * FROM OUTLINE WHERE ROOT_ID = :root ORDER BY OUTLINE_ID, POSITION

In seltenen Fällen (stark variierender Grad des Baumes) optimiere ich das Laufzeitverhalten, indem ich nur die Knoten eines Parent vorhalte oder den TITLE ausklammere und den Zugriff darauf über einen Zwischenspeicher unterstütze.

Wenn ich für einen Knoten eine vollständige Expansion brauche, dann geht das mit der oben angegebenen Query recht zügig. Es gibt da keinen Grund Hilfsattribute einzuführen, wie z.B. Zeiger auf andere Ebenen. Die Nachteile hast du ja schon selbst erkannt.

Und solltest du jemals Hilfsattribute zur Beschleunigung von Zugriffen brauchen, dann gehören diese Attribute nicht in die OUTLINE Tabelle. Sie werden entweder nur im Hauptspeicher aufgebaut und vorgehalten oder verschwinden in einer zusätzlichen Tabelle, die später über einen Join in eine View eingebracht werden kann. So bleibt dein fachliches Datenmodell unbelastet.

Freundliche Grüße vom marabu

[marabu]

Hallo Pfoto,

ich verlinke hier mal auf diesen thread - vielleicht betrifft ja der fehlende Powerset Operator auch dich?

marabu