TTreeView in SQL-Datenbank speichern?

[CG2003]

Hallo,

ist es möglich, die komplette Struktur/den kompletten Inhalt eines TreeViews in einer SQL-Datenbank zu speichern?
So quasi eine Art TTReeView.SaveToFile bloß für Datenbanken?
Ich möchte dies in einer Benutzerrechte-Datenbank verwenden, um festzulegen, auf welche Funktionen der Benutzer mittels TreeView zugreifen kann.

Hoffe ich konnte es so darstellen, das man ungefähr versteht, was ich meine...

[marabu]

Hallo Sebastian,

die gute Nachricht zuerst: die Daten einer TreeView lassen sich sehr gut in einer selbst-rekursiven Tabelle speichern.

SQL-Code:

CREATE TABLE tv (
  id INTEGER,
  tv_id INTEGER,
  caption VARCHAR(50)
)

Diese Speicherform kennen wir vom Stücklisten-Problem (bill-of-material) her. Der SQL Code dient nur zur Veranschaulichung und kann dein echtes Datenmodell nicht ersetzen. Du wirst aber erkennen, dass id als primary key fungiert und tv_id auf den übergeordneten Eintrag zeigen soll (deshalb selbst-rekursiv).

Die schlechte Nachricht ist, dass du den Code zum Speichern und Laden selbst schreiben musst, da die TreeView als common control keine Datenbank kennt - und somit auch keine entsprechenden Methoden.

Grüße vom marabu

[CG2003]

:shock: Hmm, sorry, aber irgendwie verstehe ich das nicht ganz. :?:
Scheint wohl doch etwas komplizierter zu sein, als ich dachte, oder? :wall:

[mschaefer]

Ja sieht so aus. Was willst Du ?
Den gesamten TreeView in ein Feld (Blob) oder in eine Tabelle mit den Nodes als Feldern?

Grüße // Martin

[CG2003]

Also, Beispiel:

Ich habe eine Tabelle:

Benutzer|Name|Rechte


So, und in der Spalte "Rechte" soll für jeden Benutzer das komplette TreeView so hinterlegt sein, das er nur die TreeView-Menüpunkte zu sehen bekommt, die er benutzen "darf".

Oder kann ich das noch einfacher / "eleganter" lösen?

[etom291272]

:warn: ok also zum primären verständnis wie man treeview in datenbank speichert.
ich versuche es mit einem beispiel zu veranschaulichen :!:
dieser treeview zeigt fahrzeugarten marken und modelle (abstraktes beispiel völlig egal)

der baum sieht so aus

-Motorräder---Suzuki---TL1000
------------------------GSXR
--------------Honda----CBR
-Autos--------Audi-----A4
------------------------A8
-Lastwagen


...usw

jedes Element in diesem Baum braucht jetzt eine feste nummer eine id und jedes element muss ausserdem wissen zu welchem überknoten es gehört das ergibt folgende Tabelle

Id ++++++++ ZuId +++++ Bezeichnung
------------------------------------------------
1 ++++++++ 0 ++++++++ Motorräder
2 ++++++++ 1 ++++++++ Suzuki
3 ++++++++ 2 ++++++++ TL1000
4 ++++++++ 2 ++++++++ GSXR
5 ++++++++ 1 ++++++++ Honda
6 usw.
7

siehe

Zitat:

Du wirst aber erkennen, dass id als primary key fungiert und tv_id auf den übergeordneten Eintrag zeigen soll (deshalb selbst-rekursiv).

mit dieser tabellenform kannst du jeden treeview speichern und auch wieder laden.

[Igotcha]

Zitat:

Zitat von etom291272

mit dieser tabellenform kannst du jeden treeview speichern und auch wieder laden.

Kann man, man muss aber dabei beachten, dass beim Laden die "Parents" vor den "Children" gelesen werden. Ich verwende dazu noch eine dritte Spalte, die kennzeichnet, ob es sich um einen Parent-oder Childnode handelt und sortiere meine Abfrage entsprechend, dass die Parents "oben" stehen. Meistens verwende ich auch noch eine "order"-Spalte, in der die Anordnung der Nodes gespeichert ist, um zu sagen, an welcher Position sich ein Parent befindet und an welcher Position ein Child von mehreren unter einem Parent. Das braucht man aber nur, wenn man die Nodes sortieren möchte.

Gruß Igotcha

[mschaefer]

Moin, moin,

also auf die praktische Umsetzung der allgemeinen TreeViewStruktur in eine angepasste Tabellenstruktur bin ich ja wirklich gespannt! Irgenwie beschleicht mich der Verdacht, dass hier doch noch einige nicht genannte Tücken zu erwarten sind. Deshalb gehe ich hiermit jetzt die Variante an, einen TreeView komplett in ein Blobfeld zu speichern. Damit wird meine Tabellenstruktur ziemlich banal

SQL-Code:

CREATE TABLE TUser ( 
  Pid     INTEGER, 
  Name    INTEGER, 
  Rights  BLOB       )

Stellt sich halt nur noch die Frage, wie man die Baumsstruktur in das [Rigths] Feld bekommt und wieder heraus.

Delphi-Quellcode:

{ Daten aus Blobfeld in TreeView }

procedure TableToTreeView;
var
Local_Stream: TMemoryStream;
begin
   TreeView1.Items.Clear;
   Local_Stream := TMemoryStream.Create();
   (Table1.FieldByName('Rigths') as TBlobField).SaveToStream(Local_Stream);
   Local_Stream.Seek(0, soFromBeginning);
   TreeView1.LoadFromStream(Local_Stream);
   Local_Stream.Free;
end;

Delphi-Quellcode:

{ Daten aus TreeView in Blobfeld  }

procedure TForm1.TreeViewToTable;
var
  Local_Stream: TMemoryStream;
begin
  Local_Stream:= TMemoryStream.Create();
  TreeView1.SaveToStream(Local_Stream);
  Local_Stream.Seek(0, soFromBeginning);
  (Table1.FieldByName('Rigths') as TBlobField).LoadFromStream(Local_Stream);
  Local_Stream.Free;
end;

So jetzt braucht man eigentlich nur noch eine Editkomponente oder Formular zum Bearbeiten des Treeview.


So long // Martin


PS: Unter TreeView zu Ini findet sich auch noch interessantes zumm Speichern eines Trees.

PPS: Unter DBTreeView findet sich auch eine interessante datenssensitive TreeView-Variante.

[marabu]

Sebastian, mit der Treeview in deiner Frage führst du mich aufs Glatteis, wenn du diese Komponente nur zur Visualisierung von gewöhnlichen 1:n Beziehungen verwendest. Wenn deine TreeView aber eine Menüstruktur anzeigt, dann trifft mein Beitrag aber schon ins Schwarze.

Zitat:

Zitat von CG2003

Scheint wohl doch etwas komplizierter zu sein, als ich dachte, oder?

Nichts ist schwer für den der es kann. Vielleicht verhilft dir auch das Studium der folgenden threads zu einem besseren Verständnis:

Treeview --> DbGrid Master/Detail/Detail möglich?
DB-Verknüpfungen untergeordneter Tree-Nodes anzeigen

Ich würde den Bauminhalt so speichern, wie ich es hier und in den anderen threads versucht habe zu vermitteln. Die Verwaltung der Rechte erledigt ein Beziehungstyp zwischen Benutzertabelle und der Tabelle mit den Menüeinträgen. Natürlich gibt es ganz verschiedene Wege, wie du dieses konzeptionelle Modell in eine Datenbank überführen kannst.

Grüße vom marabu

[mschaefer]

Hallo Marabu,

Denke nicht, dass Sebastian Dich aufs Gltatteis führen wollte. Welchen Weg man geht hängt sehr von den Zugriffen auf einzelne Nodes ab. Also wenn nur die Rechte statischer Benutzer in bestimmten Arbeitsphasen wechseln, dann ist sicherlich Dein Weg über die Tabellenstruktur der günstigere, da man Felder direkt anspringen kann und das langsame Blobb umgeht. Diese Zugriffe könnten damit auch noch ohne Nodefunktionen auskommen, was natürlich bei meinem Weg prinzipbedingt nicht geht.

Ein Problem habe ich allerdings mit der Tabellenstrukturvariante. Wenn Du einen variablen Tree mit variabler Nodestiefe hast, dann müßtest Du beim Einlesen, die Tabellenstruktur parsen und dass würde mich im Moment jedenfalls doch vor einige Probleme stellen, für die ich aktuell keine Lösung habe.

Grüße // Martin