Hallo! > > Ein hierarchisches Messageboard kann im Gegensatz zu einem > > Men� sehr gro� werden, daf�r werden die Knoten aber auch > > nicht hin und her geschoben, so dass hier in der Regel kein > > Trigger sondern nur eine einfache Berechnung beim INSERT > > ben�tigt wird. > > Sicher? > > A1 pos:1 > B1 pos:2 > B2 pos:3 > A2 pos:4 > A3 pos:5 > > Wenn ich jetzt zwischen B1 und B2 einen neuen Child f�r A1 einsetzen > m�chte, dann �ndert sich doch die absolute Position f�r B2, A2 und A3 > oder habe ich was falsch verstanden?
Das muss nicht sein: Ein neuer Unterknoten zu A1 w�re im Messageboard immer "B3". Zwischen "B1" und "B2" k�me nur ein Unterknoten zu "B1". Und die "absolute Position" ist keine fortlaufende Nummer, sondern z. B. so etwas wie "A0001B0001C0001". Wenn man einen gro�en Baum mit vielen �nderungen fortlaufend nummerieren m�chte, kann man die Position auch mit Vorg�nger- und Nachfolger-ID definieren und daraus per Trigger oder Stored Procedure die fortlaufende Nummerierung ermitteln. Wenn ein Knoten von Position 7 nach Position 12 verschoben wird, muss man nur die Positionen 7 bis 12 modifizieren. Beim L�schen muss man die Nummerierung gar nicht ver�ndern und beim Einf�gen "nur" die Nachfolger inkrementieren. > > > > > Hat man mehrere B�ume in der DB, hat man zus�tzlich eine TreeID. > > > > > > > > ... oder ein Kennzeichen f�r "RootID" - z. B. Parent-ID = > > NULL. Ich > > > > w�rde keine zus�tzliche Spalte f�r eine TreeID definieren. Alle > > > > Knoten mit Parent-ID = 0 sind Wurzelknoten. > > > > > > TreeIDs w�rde ich deshalb definieren, damit ich mir ohne > > irgendwelche > > > komplexen rekursiven Cursor-Geschichten in SPs mit einer > > Anfrage alle > > > Knoten eines Baumes bekomme.... > > > > > > Select * from knoten where treeID=4711 > > > > > > ... Um sie dann wie besprochen clientseitig mit rs.Filter zu > > > durchlaufen... > > > > Das kann ich ebenfalls in die "absolute Position" packen, > > indem ich die Wurzelknoten in der absoluten Position aufnehme > > und dann direkt mit "BETWEEN" oder "LIKE '...%'" filtere. Ich > > hab doch schon zus�tzlich die absolute Position. ;-) > > Ja, aber dann muss ich zus�tzlich irgendwo speichern: Baum1 geht von 123 > bis 456, Baum2 von ... Bis ... N�, Wurzelknoten sind die, "WHERE parentId is null" oder "where parentId < 0". Mein 7. Menu starte ich einfach mit "where pid = -7". Die negative Zahl entspricht dabei Deiner TreeID. ;-) > > Wenn man ein Men� auf z. B. 4 Ebenen begrenzt, kann man ein > > hierarchisches Recordset erzeugen ... > > > > Klar. Das k�nnte man sogar dazu nutzen, damit man immer n(n>1) Ebenen > vorausschauen kann, wenn man schon immer zur DB gehen will... Also so, > wie Dein erstes Beispiel, nur dass man weniger oft Anfragen stellen > muss, weil man sich von einem Knoten nicht nur die n�chste Ebene geben > l�sst, sondern die n�chsten 2 oder 3... > > > > > ... und dieses entweder sequentiell abarbeiten oder direkt > > als XML-Datei speichern. In der Web-Applikation wird das Men� > > dann aus der XML-Datei generiert. > > > > In der Tat.... Kann nichts schaden, wenn man ein rekursives Konstrukt > auch in einer rekursiven Datenstruktur speichert.... Genau, Menus sind schon wegen der Usability so klein, dass eine XML-Datei eigentlich ausreicht. Warum nicht einfach ein XML-Object im Filesystem oder in eine TEXT-Spalte ablegen?! Freundliche Gr��e Joachim van de Bruck > > Claudius | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
