Comme toujours :il n'y a pas de meilleure solution. Chaque solution rend différentes choses plus faciles ou plus difficiles. La bonne solution pour vous dépend de l'opération que vous effectuerez le plus.
Approche naïve avec parent-id :
Avantages :
-
Facile à mettre en œuvre
-
Déplacer facilement un grand sous-arbre vers un autre parent
-
L'insert est bon marché
-
Champs nécessaires directement accessibles en SQL
Inconvénients :
-
Récupérer un arbre entier est récursif et donc coûteux
-
Trouver tous les parents coûte aussi cher ( SQL ne connaît pas les récursions... )
Parcours de l'arborescence de précommande modifié (enregistrement d'un point de départ et d'un point final) :
Avantages :
-
Récupérer un arbre entier est facile et peu coûteux
-
Trouver tous les parents n'est pas cher
-
Champs nécessaires directement accessibles en SQL
-
Bonus :vous enregistrez également l'ordre des nœuds enfants dans son nœud parent
Inconvénients :
- L'insertion/la mise à jour peut être très coûteuse, car vous devrez peut-être mettre à jour de nombreux nœuds
Enregistrer un chemin dans chaque nœud :
Avantages :
-
Trouver tous les parents n'est pas cher
-
Récupérer un arbre entier n'est pas cher
-
L'insertion est bon marché
Inconvénients :
-
Déplacer un arbre entier coûte cher
-
Selon la manière dont vous enregistrez le chemin, vous ne pourrez pas l'utiliser directement dans SQL. Vous devrez donc toujours le récupérer et l'analyser si vous souhaitez le modifier.
Tableau de clôture
Avantages :
-
Facile à mettre en œuvre
-
Trouver tous les parents n'est pas cher
-
L'insertion est bon marché
-
Récupérer des arbres entiers est bon marché
Inconvénients :
-
Nécessite une table supplémentaire
-
Prend beaucoup de place par rapport aux autres approches
-
Déplacer un sous-arbre coûte cher
Je préférerais l'un des deux derniers, en fonction de la fréquence à laquelle les données changent.
Voir aussi :http://media.pragprog.com/titles/bksqla/trees. pdf
