web-dev-qa-db-fra.com

Quelles sont les méthodes connues pour stocker une structure arborescente dans une base de données relationnelle?

Il y a la méthode "mettre un FK à votre parent" , c'est-à-dire que chaque enregistrement pointe vers son parent.
Ce qui est difficile à lire mais très facile à entretenir.

Et puis il y a une méthode "clé de structure de répertoire":

0001.0000.0000.0000 main branch 1
0001.0001.0000.0000 child of main branch one
etc

Ce qui est super facile à lire, mais difficile à entretenir.
Quels sont les autres moyens et leurs inconvénients/avantages?

mysqldesign-patternstreerelational-database
39
Itay Moav -Malimovka

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 l'ID parent:

Avantages:

  • facile à mettre en œuvre

  • facile de déplacer un gros sous-arbre vers un autre parent

  • insérer est pas cher

  • Champs nécessaires directement accessibles en SQL

Les 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 ...)

Traversée de l'arborescence de précommande modifiée (enregistrement d'un point de début et de fin):

Avantages:

  • Récupérer un arbre entier est facile et bon marché

  • 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

Les inconvénients:

  • L'insertion/la mise à jour peut être très coûteuse, car vous devrez peut-être mettre à jour un grand nombre de nœuds

Enregistrement d'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é

Les inconvénients:

  • Déplacer un arbre entier coûte cher

  • Selon la façon dont vous enregistrez le chemin, vous ne pourrez pas travailler directement avec lui dans SQL, vous devrez donc toujours le récupérer et l'analyser, si vous souhaitez le modifier.

Je préfère l'un des deux derniers, selon la fréquence à laquelle les données changent.

Voir aussi: http://media.pragprog.com/titles/bksqla/trees.pdf

49
Baju

Traversée de l'arbre de précommande modifiée

Il s'agit d'une méthode qui utilise une fonction non récursive (généralement une seule ligne de SQL) pour récupérer les arbres de la base de données, au prix d'être un peu plus délicate à mettre à jour.

Diagram showing numbered hierarchical tree **

Section 2 de l'article Sitepoint Stockage de données hiérarchiques dans une base de données pour plus de détails.

18
TRiG

Je dirais que la "voie d'or" pour stocker une structure de données hiérarchique consiste à utiliser une base de données hiérarchique. Tels que, par exemple, HDB. C'est une base de données relationnelle qui gère assez bien les arbres. Si vous voulez quelque chose de plus puissant, LDAP pourrait faire pour vous.

Une base de données SQL n'est pas adaptée à cette topologie abstraite.

4
Borealid

Je ne pense pas qu'il soit difficile de construire une arborescence avec une base de données relationnelle.

Cependant, une base de données orientée objet fonctionnerait beaucoup mieux à cette fin.

Utilisation d'une base de données orientée objet:

parent has a set of child1  
child1 has a set of child2  
child2 has a set of child3  
...  
...

Dans une base de données orientée objet, vous pouvez créer cette structure assez facilement.

Dans une base de données relationnelle, vous devrez conserver des clés étrangères au parent.

parent  
id  
name  

child1  
parent_fk  
id  
name 

child2  
parent_fk  
id  
name  

..

Essentiellement, pendant que vous construisez votre arborescence, vous devrez joindre toutes ces tables, ou vous pouvez les parcourir.

foreach(parent in parents){
   foreach(child1 in parent.child1s)
    foreach(child2 in child1.child2s)

...
0
DarthVader