> > 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".
Hab mir schon gedacht, dass Du mit sowas kommst, aber das ist doch nicht wirklich sch�n oder? Das macht mir ein ungutes Gef�hl.... Entweder beschr�nke ich hier die Baumtiefe oder es wird langsam(text)... Und f�r den Index wird doch sowieso nur die ersten 256(!?) chars benutzt... In tieferen Ebenen bekommt man also Fehler ... :( > > 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. Diesen Aufwand wollte ich halt vermeiden... Ist aber vielleicht in einer SP besser aufgehoben, als in VBS... Kommt darauf an, ob man nur einen Teilbaum, ooder alles haben will... [..] > 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. ;-) Aber dann kann man parentID nich als FK(+Konsistenzcheck) definieren... Das m�sste gerade Dir doch Bauchschmerzen bereiten... [..] > > > > 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?! > Genau, oder gleich im FileSystem(mit Applikation-Objekt-Cache)... Solche Men�s sind ja normalerweise sowieso nicht in beliebiger Anzahl vorhanden... Also: - F�r kleine Hierarchien, die selten ge�ndert werden, ist Ablage als XML optimal - F�r (viele) kleine Hierarchien, die oft ge�ndert werden(z.B. threaded Forum) w�rde ich aber im Moment noch auf meine treeID(in diesem Fall threadID) bestehen, dann immer den kompletten tree/thread auf einmal in ein disconnected RS packen und das rek. Sortieren in VBS machen - F�r (massiv-)grosse selten ge�nderte Hierarchien lohnt die Berechnung einer absoluten Position wahrscheinlich trotzdem nicht... Im �nderungsfall ergeben sich zu viele �nderungen... Hier empfiehlt sich wahrscheinlich SP, die den gew�nschten Ausschnitt generiert - F�r (mittel-)grosse selten ge�nderte Hierarchien k�nnte sich die Berechnung einer absoluten Position lohnen, wenn man alles an Performance im Lesesfall rausholen will. - F�r grosse oft ge�nderte Hierarchien ist wohl wieder der Einsatz von SPs anzuraten. Was meinst Du? 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
