Hmm... warum trägst du nicht diese baumstruktur per einfachem nach oben verkettetem Baum (sagen wir einfach mal binary tree) in die
DB ein (so wies jetzt schon ist, über ID und Parent_Id) und liest die Rechte dann dynamisch aus? Es muss ja bestimmte Abfrageszenarien geben, z.B. "alle Rechte bei Knoten x".
Die Rechte bei Knoten x ergeben sich ja aus den Werten bei sämtlichen leafs. das heißt, du gehst erkursiv durch deine Datenbank und suchst dir erst mal alle Knoten, deren Parent_Id x ist.
Dann gehst du diese Knoten durch und fragst "Ist dieser Knoten eni leaf"? Falls ja, liest du seinen Wert aus und fügst in in die ergebnismenge ein. falls nein, fängst du von vorne an: du suchst wieder alle Knoten, deren Parent_Id die Id dieses Knotens ist.
Das ist natürlich nicht besonders perfromant. Ich würde das deswegen in zwei Tabellen aufteilen, eine Tabelle mit leafs und eine tabelle, in die du einen binärbaum schreibst. dann kannst du dich zügig von Knoten x zu allen seinen childs durchhangeln.
Und einfügen in die
db sollte auch nicht schwierig sein:
du suchst dir erst den knoten, an dem du einfügen willst(sei x). sind bereits beide Äste besetzt, erstellst du einen neuen Datensatz(sei y), dessen Parent_ID setzt du auf x. Das A-Feld von x setzt du auf y. Ans A-Feld von y hängst du nun einen neuen Datensatz, der nicht mehr weiter verzweigt sondern auf ein leaf verweist. Als B-Feld setzt du nun das, was gerade in der Luft hängt, nämlich das alte A-Feld von x.
Soweit verständlich?
Nochmal kurz:
BINARY_TREE ( INT id auto_increment, INT Parent, INT A, INT B, INT leaf)
LEAFS (INT id auto_increment, INT value)
Das kann man natürlich noch weiter optimieren, indem man das leaf-feld durch ein falg ersetzt, bei dessen gesetztheit A und B nicht mehr weiterverzweigen sondern leafs sind. die leafs-tabelle fällt dann weg und du musst beim durchrekursieren nur schauen, ob das flag gesetzt ist, falls nein, gehts weiter, falls ja, schreibst du die werte in deine ergebnismenge.
Alle Klarheiten beseitigt?
