Designen av Nested Sets är definitivt svår när du behöver göra frekventa uppdateringar av trädet. Det slutar med att du måste numrera om stora delar av trädet.
Ett förslag för att mildra detta är att använda flyttal istället för heltal. Om du infogar en ny nod i trädet är det relativt lätt att hitta några FLOAT-nummer mellan de kapslade uppsättningsnumren för den nya nodens överordnade. Du kan så småningom komma till gränserna för precisionen för ett flyttal, men eftersom ditt träd inte är särskilt djupt kommer det inte att hända på länge.
En annan teknik som jag har skrivit om kallar jag Stängningstabell . Denna metod för att lagra hierarkier gör det mycket lättare att infoga/uppdatera/ta bort noder i ett stort träd utan att behöva uppdatera mycket av ditt träd. Och du kan fortfarande fråga hela trädet eller vilket underträd som helst i en enda icke-rekursiv SQL-fråga.
För att läsa mer om Closure Table, se:
- Vad är det mest effektiva/eleganta sättet att analysera ett platt bord till ett träd?
- Modeller för hierarkisk data med SQL och PHP
- Flytta underträd i stängningstabellhierarkier
- SQL Antipatterns:Avoiding the Pitfalls of Database Programming
Angående din kommentar:
Adjacency List är enkel, har ett minimum av redundans och den stöder FK-relationer, vilket Nested Sets inte har. Adjacency List stöder sökning av ett helt träd av godtyckligt djup om du använder rekursiva frågor . Men MySQL stöder inte rekursiva frågor.
Om du bara behöver fråga omedelbara förälder-barn-relationer (dvs. en nivå av djup), eller på annat sätt bara fråga efter träd med fast djup, är Adjacency List bra.