Hallo Pfoto,
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:
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