Sub-Tree Abfrage mit NestedSet Model

Stammverzeichnis
- Unterverzeichnis1
- - Unterunterverzeichnis1
- - - Datei 1
- - - Datei 2
- - - Datei 3
- - Unterunterverzeichnis2
- - - Datei 1
- - - Datei 2
- - - Datei 3
- - Unterunterverzeichnis3
- Unterverzeichnis2
- - Unterunterverzeichnis1
- - Unterunterverzeichnis2
- - Unterunterverzeichnis3
- - - Datei 1
- - - Datei 2
- - - Datei 3
- Unterverzeichnis3
- - Unterunterverzeichnis1
- - - Datei 1
- - - Datei 2
- - - Datei 3
- - Unterunterverzeichnis2
- - Unterunterverzeichnis3

Stammverzeichnis
- Unterverzeichnis1
- - Unterunterverzeichnis1
- - Unterunterverzeichnis2
- - - Datei 1
- - - Datei 2     <--
- - - Datei 3
- - Unterunterverzeichnis3
- Unterverzeichnis2
- Unterverzeichnis3

Ich sehe keinen Weg das zu bewerkstelligen :/

Hi Gardan

Ich habe seit Do an einer Lösung gearbeitet und nix gefunden.
Durch Zufall hat ein Freund von mir (2ton3) einen Beitrag auf einen Beitrag (php4-forum.de) gefunden, der das Thema behandelt.

Der Lösungs Weg:
Von der gewählten ID, wird zuerst der direkte Weg zum Root ermittelt
und durch dieses Resultat kann dann ein Having-Klausel erstellt werden, die dann den Rest macht.

So kann man das Menu + Tree und BrotkrummenNavigation (YouAreHere // Vor-Sql) mit 2 Sqls abbilden.

Wenn gewünscht hänge ich die Front-End-Klasse an

Hmm mich würde mal interessieren wie schnell das ein gutes SQL Backend hin kriegt... insbesondere würde mich da die Komplexitätsklasse interessieren

Optimalerweise müsste man wohl auf left und right nen Index bauen, macht aber das Einfügen schon sehr teuer...

HI Garden

Sicher ist diese Art von Menü-Speicherung etwas aufwendiger als andere.

Aber wenn man sich das ganze genau überlegt, geht es nicht um die Speicherung, sondern um die Ausgabe.
Denn ich werde viel öfter das Menü Ausgeben müssen, als einen Menüpunkt hinzufügen oder sonst wie manipulieren.

Da nehme ich gerne die mehr Aktionen beim Bearbeiten in Kauf, als sie vorne zu haben.

Angehängte Dateien

class_nested_display.txt (5,9 KB, 518x aufgerufen)

Selbst die Ausgabe ist einigermaßen komplex meine ich Zumindest, für so kleine Menustrukturen lohnt es sich meiner Meinung nach nicht... schon eher vielleicht für Antworten in einem Topic, aber selbst da müssten es schon an die 100 sein damit es sich lohnt meine ich... weil zb bei 100 Stück da hab ich schnell mal id und parent id rausgeholt, in linearzeit O(n) die Struktur aufgebaut und kann dann selektiv die interessanten aus der Datenbank komplett rauspflücken...

Hi @gain

Ich verwende das ganze für ein CMS
Generell gebe ich dir recht, wobei man immer Unterscheiden muss, welche Art von Navigation du hast.

Wenn du immer alle Menü-Punkt sichtbar hast, zB Ausklapp-Menü,
brauchst du genau 1 SQL für die Menü-erstellung

Wenn es ein Tree-Menü ist, welches die Haupt-Menü-Ebene und je nach Position in der Seite den Tree ausgibt, brauchst 2 Sql.

Der Aufwand steht sich in meinen Augen dafür.
In einem Forum würde ich es nicht verwenden, wobei möglich, da viel öfter ein Beitrag geschrieben wird, und so der Berechnungs-Aufwand (Linke und rechte ID) zu groß wäre.

Ich hab mal einiges drüber gelesen im www und ich würde dir raten zu erwägen einen zusätzlichen Depth-Wert zu speichern. Ansonsten ist die Struktur eigentlich ganz ok - nur eine Sache die mir fehlt: Wie lösch ich effizient mehrere Einträge auf einmal? :/

HI Gardan

In meiner Stuktur wird das Level mitgespeichert, und muss nicht mehr berechnet werden.

Wie ich schon oben gesagt habe, ist das die Frontend-Klasse, da brauch ich nix manipulieren.

Wenn dich das Thema interessiert, lies dir den Artikel auf Develnet.org durch.
Auf Seite 4 (Manipulation der Baumstruktur) findest du die Möglichkeit, wie du löscht.

Ja, leider nur ein Blatt oder einen Teilbaum. Wenn ich aber eine beliebige Anzahl beliebiger Knoten löschen will wirds schwierig...

Hi @gain

wird durch die verschiedenen Updates (Nachberechnung) schwer, würde sogar sagen, das das nur mit einer Schleife geht.

Darf ich wissen wofür du sowas brauchen würdest??

Wahrscheinlich wärs am einfachsten das ganze neu zu berechnen... muss ich mal suchen ob sich das einigermaßen schnell machen lässt...

Wofür? Nja ich bin immer noch sehr angetan von der Idee Topics auch Threaded darzustellen... trotz der großen visuellen und datenbanktechnischen Probleme Vielleicht is es auch gerade diese Herausforderung

http://www.karlnelson.net/nestedlists/

keine Ahnung ob dir das hilft aber die Seite ist mir gerade beim surfen aufgefallen..

mfg
jens

Naja, wenn dann schon per XMLHttpRequest Aber das Problem mit dem löschen vieler Einträge is immer noch da, genauso wie das Splitten in 2 getrennte Topics...

@Gardan

Ich würde Nested Set nicht für ein Forum verwenden, dieses Model ist für Darstellungen gedacht die sich nicht sehr häufig ändern.

Bei einem Forum ist der Berechnungs-Aufwand zu groß

Andre Idee für Foren? Hab noch nix gefunden dazu leider... Preorder & Postorder zu speichern hätte den gleichen Effekt und die gleichen Nebenwirkungen Vielleicht reicht einfah Depth mit zu speichern... das würde immerhin schonmal vieles vereinfachen...

Hi @gain

Ich überleg mir was, vielleicht fällt mir was nettes ein.

Bei Nested Set wirst um die neu berechnung ned hinweg kommen, egal ob du die Levels = Deeps mitspeicherst.
Dadurch wird nur die Ausgabe schneller, da sie ned mehr berechnet werden muss.

Jap, das is aber immerhin schonmal was weil dermaßen oft löscht man ja keine Postings...

Hast du dir das Einfügen angeschaut??

Du rechnest alle Rechten Nachbarn nach.

Das kann ned gesund sein auf dauer *fg*

Nja... das ließe ich aber grade noch durchgehen Bloß das mit dem Löschen is der Killer... nur was gibts bessres? Google findet nix

Irgendwie scheints echt nix andres zu geben...
http://www.openwin.org/mike/presenta...erarchical.pdf