Hallo! Wenn Dein Baum groß genug ist macht die Nutzung des Nested Set Algorithmus immer Sinn. Achte drauf, daß Du "better nested set" nutzt, eine Überarbeitung / Erweiterung, die ein paar Probleme beseitigt und zusätzliche Funktionalität wie die Behandlung von Teilbäumen unterstützt.
> Ein Schraubendreher ist Teil des Satzes "Schraubendreher Paket", > dies ist Teil des Satzes Werkzeugkasten, dies ist Teil des > Satzes Fahrzeug. Baum, mehrere Bäume? Du kanst mehrere Bäume im selben Modell / Tabelle halten, wenn Du den scope Parameter nutzt, um die einzelnen Bäume zu unterscheiden. > Dabei können z.B. diese Use-Cases auftreten: > a) Der Werkzeugkasten wird vom Fahrzeug genommen und eingelagert. Teilbaum um- / aushängen? Sollte mit better nested set gehen. Bitte nochmal Doku checken. > b) Das Schraubendreher Set ist nicht mehr Teil eines Werkzeugkasten, > sondern wird direkt in der Werkstatt an die Wand gehangen. s.o. > c) Zu einem Satz (oder Teil) liegt ein Defekt vor, der erfasst werden muss. has_many :defects? > Ich überlege gerade, das ganze in ein nested-Set zu überführen. > Was haltet ihr davon? Hängt von der Größe und vor allem Tiefe ab. > - Kann ich a_a_n_s genauso verwenden wie a_a_t? D.h. parent_id setzen > und gut ist's, oder muss ich mich in einem der o.g. UC-Cases noch um > left, right, etc. kümmern. Node erzeugen und einhängen. Ggf. scope setzen. Mehr ist nicht. Mit left und right hast Du nichts zu tun. > Im Use-Case b) würde sich sogar der Scope ändern - da nun der > Schraubendrehersatz nicht mehr Mitglied der Listen Werkzeugkasten, > Fahrzeug ist. Kann Rails das automatisch? Ah. Hätte ich mal vorher komplett lesen sollen: Better nested set sollte das können. > Ich stelle es mir ein wenig haarig vor, Scopes manuell zu führen, > da jeder Knoten im Baum eine Wurzel eines potentiellen Baums ist > und bei einem Zerlegen der Baumstruktur neue Scopes gesetzt werden > müssten .. oder kann Rails das automatisch? Wenn Du auf scopes verzichten müstest könntest Du ja alles in einem Baum (mit einem Root Element) halten. > - Im Fall einer Migration müsste ich die vorhandene DB-Struktur > in das neue Format migrieren. Das hinzufügen der Spalten wird > natürlich kein Problem sein - gibt es aber einen einfach Weg, die > neuen Attributes (lft, fgt, root, scope) zu setzen, oder ist hier > SQL-Handarbeit gefragt? Nochmal, bis auf parent und ggf. scope läuft alles automatisch. Eine Migration sollte problemlos sein, wenn Du weißt, wie Du Deinen Originalbaum traversieren mußt. Ich habe mal kurz mit acts as tree und better nested set rumgespielt. Mit der Teilbaumfunktionalität (löschen, verschieben, etc.) bin ich mir zwar nicht 100% sicher, aber ich denke das war die Hauptmotivation für die Überarbeitung. Kann sein, daß ich Deine Fragen falsch interpretiert habe, kannst gern nochmal korrigieren / nachfragen. Am besten Du spielst einfach mal damit in der console rum. Mehr als 30 Minuten, max. eine Stunde sollte Dich das nicht kosten. Gruß! - Bernd
<<winmail.dat>>
_______________________________________________ rubyonrails-ug mailing list [email protected] http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
