Som alltid:det finns ingen bästa lösning. Varje lösning gör olika saker lättare eller svårare. Den rätta lösningen för dig beror på vilken operation du kommer att göra mest.
Naiv metod med föräldra-id:
Fördelar:
-
Lätt att implementera
-
Lätt att flytta ett stort underträd till en annan förälder
-
Insatsen är billig
-
Nödvändiga fält direkt tillgängliga i SQL
Nackdelar:
-
Att hämta ett helt träd är rekursivt och därför dyrt
-
Att hitta alla föräldrar är också dyrt (SQL känner inte till rekursioner...)
Ändrad förbeställningsträdövergång (spara en start- och slutpunkt) :
Fördelar:
-
Att hämta ett helt träd är enkelt och billigt
-
Att hitta alla föräldrar är billigt
-
Nödvändiga fält direkt tillgängliga i SQL
-
Bonus:du sparar ordningen på underordnande noder inom dess överordnade nod också
Nackdelar:
- Infoga/uppdatering kan bli mycket dyrt, eftersom du kanske måste uppdatera många noder
Spara en sökväg i varje nod:
Fördelar:
-
Att hitta alla föräldrar är billigt
-
Att hämta ett helt träd är billigt
-
Att infoga är billigt
Nackdelar:
-
Att flytta ett helt träd är dyrt
-
Beroende på hur du sparar sökvägen kommer du inte att kunna arbeta med den direkt i SQL, så du måste alltid hämta och analysera den om du vill ändra den.
Stängningstabell
Fördelar:
-
Lätt att implementera
-
Att hitta alla föräldrar är billigt
-
Att infoga är billigt
-
Att hämta hela träd är billigt
Nackdelar:
-
Behöver ett extra bord
-
Tar mycket plats jämfört med andra tillvägagångssätt
-
Att flytta ett underträd är dyrt
Jag föredrar en av de två sista, beroende på hur ofta data ändras.
Se även:http://media.pragprog.com/titles/bksqla/trees. pdf