Come sempre:non esiste una soluzione migliore. Ogni soluzione rende le cose diverse più facili o più difficili. La soluzione giusta per te dipende dall'operazione che farai di più.
Approccio ingenuo con ID genitore:
Pro:
-
Facile da implementare
-
È facile spostare un grande sottoalbero su un altro genitore
-
L'inserimento è economico
-
Campi necessari direttamente accessibili in SQL
Contro:
-
Recuperare un intero albero è ricorsivo e quindi costoso
-
Anche trovare tutti i genitori è costoso ( SQL non conosce le ricorsioni... )
Attraversamento dell'albero del preordine modificato (salvataggio di un punto iniziale e finale) :
Pro:
-
Recuperare un intero albero è facile ed economico
-
Trovare tutti i genitori è economico
-
Campi necessari direttamente accessibili in SQL
-
Bonus:stai salvando anche l'ordine dei childnodes all'interno del parentnode
Contro:
- L'inserimento/l'aggiornamento può essere molto costoso, poiché forse dovrai aggiornare molti nodi
Salvataggio di un percorso in ciascun nodo:
Pro:
-
Trovare tutti i genitori è economico
-
Recuperare un intero albero è economico
-
L'inserimento è economico
Contro:
-
Spostare un intero albero è costoso
-
A seconda del modo in cui salvi il percorso, non sarai in grado di lavorarci direttamente in SQL, quindi dovrai sempre recuperarlo e analizzarlo, se vuoi cambiarlo.
Tabella di chiusura
Pro:
-
Facile da implementare
-
Trovare tutti i genitori è economico
-
L'inserimento è economico
-
Recuperare alberi interi è economico
Contro:
-
Ha bisogno di un tavolo aggiuntivo
-
Occupa molto spazio rispetto ad altri approcci
-
Spostare un sottoalbero è costoso
Preferirei uno degli ultimi due, a seconda della frequenza con cui i dati cambiano.
Vedi anche:http://media.pragprog.com/titles/bksqla/trees. pdf
