[LioGetz]

Hi @ all...

ich hab mal wieder ein kleines Verständnis-Problem .

Folgendes: Für ein etwas größeres Projekt habe ich mich mal wieder schlau gemacht, welche Art und Weise "die Beste" ist, um ein (hierachisches) Menü dynamisch aus ner DB zu laden.
Dabei bin ich auf "Nested Sets" gestoßen und mir diverse Artikel dazu durchgelesen. Ein häufig herangezogener Beitrag ist dieser hier.

Die "Logik" hinter den Nested Sets und die Vorteile habe ich soweit verstanden, nur irgendwie haperts bei mir noch bei der praktischen Verwendung.
Ich hab ne DB aufgezogen (wie im Artikel: mit ID, Name, lft, rgt) und mit Testeinträgen gefüllt (bis zu drei "Menüebenen" tief). Soweit - so gut...und jetzt?

Wie bekomme ich das Menü so ausgelesen, wie es in dem Beispiel aussieht??

[pixelpapst303]

wenn du den klempert schon hier nennst, dann downloade doch auch seine demoklasse mit treemanager...

http://www.klempert.de/nested_sets/

(download oben rechts)

[LioGetz]

jaja...danke, aber das hatte ich schon gemacht...das hat mir aber nicht wirklich weiter geholfen...
Zum einen ist das für mich zu überdimensioniert, zum zweiten verstehe ich es dann immer noch nicht...
"Der Clou" ist einfach "irgend n Schleifenkonstrukt" um die Daten (anhand der Ebenen) hierarchisch auszugeben...nur wie das geht - das ist ja mein Problem

Sowas wie im Folgenden soll die Ausgabe sein, aber ich versteh einfach nicht wie man das Anhand der Nested Set Daten in der DB ausgeben bekommt...ich dachte das Modell wäre so dafür geeignet um hierarchische Strukturen auszugeben ??

[pixelpapst303]

im grunde brauchst du in deinem beispiel doch "nur" jeweils das level vom aktuellen eintrag mit dem vom nächten eintrag vergleichen. in php sind da next() und current() - (arrayfunktionen) deine freunde.

wenn next dann größer current is, geht n ul auf. wenns kleiner is, ein ul zu. wenns gleich is passiert nüschts...

[bacon]

Da du über ne Relation gehst und das ganze natürlich keine verschachtelten Objektrepräsentation zurück gibt, wirst du dein Menu eigends über das Einrückungslevel generieren müssen (Diese Beispiel-Monsterqueries dazu liefern das als Attribut an einem Tupel mit).

Aber mal ehrlich. Warum willste das überhaupt machen? Nimm dir doch ein array bzw. ein Objekt und speichere einfach die serialisierte Repräsentation in der Datenbank (bspw. als Xml, Json, per serialize()) => Fertisch. Nested sets sind zwar eine eine geniale "es geht doch mit rdbs"-Lösung, aber irgendwie trotzdem recht teuer. Nicht so sehr bei der Ausgabe, aber die Einfügeoperationen sind schon ne Wissenschaft für sich, die Transaktionen nicht sehr performant.

[LioGetz]

hmmm...und ich habe fast vermutet das sowas kommt^^

Seltsam, dabei hab ich an mehreren Quellen gelesen das man Nested Sets für Hierarchische Strukturen nutzt (Menüs, Breadcrumber Navigation etc.)...wenn es dafür "so sinnvoll" sein soll, dann frag ich mich warum es so kompliziert ist, bzw. im Netz (oder an den oben zitierten Quellen) keine Bsp. dafür gibt ??!!
Der Standard um ne Navi aus ner DB zu holen ist ja "ID | Name | Parent" Angaben zu machen...um Anhand des Parents zu wissen auf welcher Ebene der jeweilige Menüpunkt steht.

Aber ich dachte einfach "mach mal was professionelleres" was ja angeblich auch besser sein soll...also ihr meint dass das Quatsch ist für n normes Menü??

CU
Lio

[bacon]

Ich hab auch dauernd "nested sets" gebrüllt, wenn mal nach Bäumen gesucht wurde. Aber im Endeffekt hat mir die Erfahrung gezeigt, dass das schon eher Exotenstatus genießt. Es kann sicher im Grenzfall von Vorteil sein, aber mir will jetzt keiner Einfallen.

Große Bäume: Lädst du in den Primärspeicher
Kleine Bäume: Gehen sowieso sehr performant über ein hierarchisches Format im Dateisystem oder alternativ als serialisiertes, hierarchisches Format in einem Datenbankfeld.

Einfügeoperationen sind bei großen Bäumen in Strukturformaten und bei Nested Sets - wage ich einfach mal zu behaupten - gleich teuer, bzw. ich glaube sogar, dass die NestedSets-Transaktionen teurer sind.

Andererseits ist bspw. mysql mit der myisam-engine schon höllisch schnell, sogar n-prozesse * m Queries in einer Transaktion sind eigentlich kein Problem. Wenn du die Herausforderung nicht scheust, sind NestedSets somit also schon eine Alternative.

In anderen StorageEngines würde ich es nicht empfehlen, und andere DBS haben eh proprietäre Funktionen, um bspw. Parent-Child-Beziehungen auszuwählen oder xml-bäume zu durchwandern.

[LioGetz]

ich versteh zwar nur die hälfte von dem was du mir sagen willst - aber ich schließe mal daraus:

OK, ist schwachsinn für ein "einfaches Menü" wenn es auch anders einfacher zu realisieren ist

Danke für die Infos

CU
Lio