MongoDB - enfants et structure parent

Vous devez tenir compte du type de requêtes que vous devrez effectuer et de la fréquence à laquelle chaque type sera nécessaire. Lorsque je travaillais sur quelque chose de similaire, j'ai proposé six actions possibles :

• Faire quelque chose avec le parent
• Faire quelque chose avec les enfants
• Faire quelque chose avec les ancêtres (parents de parents, parents de parents de parents, etc.)
• Faire quelque chose avec les descendants (enfants d'enfants, enfants d'enfants d'enfants, etc.)
• Modifier les relations (ajouter/déplacer/supprimer des nœuds dans la hiérarchie)
• Modifier les données principales dans le nœud actuel (ex. changer la valeur dans le champ "titre")

Vous voudrez estimer l'importance de chacun d'entre eux pour votre application.

Si la majeure partie de votre travail consiste à travailler avec des données stockées pour un article donné, y compris son parent immédiat et ses enfants, la première idée est le plus utile. En effet, dans MongoDB, il est assez courant de placer toutes les informations dont vous avez besoin dans le même document plutôt que de les référencer en externe afin que vous n'ayez qu'à récupérer une chose et à travailler uniquement avec ces données. Les quatre dernières actions de la liste sont cependant plus délicates.

En particulier, vous devrez parcourir l'arborescence pour récupérer les ancêtres et les descendants dans ce cas, en parcourant les documents intermédiaires et en suivant un chemin, même si vous ne vous souciez que du dernier document du chemin. Cela peut être lent pour les longues hiérarchies. La modification des relations peut nécessiter le déplacement d'un grand nombre d'informations dans plusieurs documents en raison de toutes les données présentes dans chacun d'eux. Mais même changer un seul champ comme "titre" peut être ennuyeux, car vous devez tenir compte du fait que ce champ est présent dans plusieurs documents différents, soit en tant que champ principal, soit sous les champs parent ou enfant.

En gros, votre première idée fonctionne mieux dans les applications statiques où vous ne modifierez pas beaucoup les données après les avoir initialement créées, mais où vous devrez les lire régulièrement.

La documentation MongoDB a cinq approches recommandées pour gérer les structures arborescentes (hiérarchiques). Tous ont des avantages et des inconvénients différents, bien qu'ils facilitent tous la mise à jour des données principales d'un article en n'ayant besoin de le faire que dans un seul document.

• Références parentales :chaque nœud contient une référence à son parent.
• Avantages :
  • Recherche parent rapide (recherche par "_id" =titre de votre document, renvoie le champ "parent")
  • Recherche rapide des enfants (recherche par "parent" =le titre de votre document, qui renverra tous les documents enfants)
  • La mise à jour des relations consiste simplement à modifier le champ "parent"
  • La modification des données sous-jacentes nécessite de modifier un seul document
• Inconvénients :
  • La recherche par ancêtres et descendants est lente, nécessitant une traversée
• Références enfant :chaque nœud contient un tableau de référence à ses enfants
  • Avantages :
    • Récupération rapide des enfants (renvoie le tableau des enfants)
    • Mise à jour rapide de la relation (il suffit de mettre à jour le tableau des enfants si nécessaire)
  • Inconvénients :
    • Pour trouver un parent, il faut rechercher votre _id dans tous les tableaux enfants de tous les documents jusqu'à ce que vous le trouviez (puisque le parent contiendra le nœud actuel en tant qu'enfant)
    • La recherche d'ancêtres et de descendants nécessite la traversée de l'arbre
• Tableau d'ancêtres  :chaque nœud contient une référence à un tableau de ses ancêtres et de son parent
  • Avantages :
    • Récupération rapide des ancêtres (pas de traversée nécessaire pour en trouver un spécifique)
    • Recherche facile des parents et des enfants en suivant l'approche "Parent References"
    • Pour trouver des descendants, recherchez simplement les ancêtres, car tous les descendants doivent contenir les mêmes ancêtres
  • Inconvénients :
    • Vous devez vous préoccuper de la mise à jour du tableau d'ancêtres ainsi que du champ parent chaque fois qu'il y a un changement dans les relations, souvent sur plusieurs documents.
• Chemins matérialisés :chaque nœud contient un chemin vers lui-même - nécessite regex
  • Avantages :
    • Facile à trouver des enfants et des descendants à l'aide de regex
    • Peut utiliser un chemin pour récupérer le parent et les ancêtres
    • Flexibilité, telle que la recherche de nœuds par des chemins partiels
  • Inconvénients :
    • Les modifications de relations sont difficiles, car elles peuvent nécessiter des modifications des chemins d'accès à plusieurs documents
• Ensembles imbriqués :Chaque nœud contient un champ "gauche" et "droit" pour aider à trouver les sous-arbres
  • Avantages :
    • Récupération facile des descendants de manière optimale en recherchant entre "gauche" et "droite"
    • Comme l'approche "Parent Reference", il est facile de trouver un parent et des enfants
  • Inconvénients :
    • Nécessité de traverser la structure pour trouver des ancêtres
    • Les changements de relation sont les moins performants ici que toute autre option, car chaque document de l'arborescence peut devoir être modifié pour s'assurer que "gauche" et "droite" ont toujours un sens une fois que quelque chose change dans la hiérarchie

Les cinq approches sont décrites plus en détail dans la Documentation MongoDB .

Votre deuxième idée combine les approches « Références parents » et « Références enfants » décrites ci-dessus. Cette approche facilite la recherche des enfants et du parent et facilite la mise à jour des relations et des données principales d'un article (bien que vous deviez mettre à jour les champs parent et enfants), mais vous devez toujours le parcourir. pour trouver des ancêtres et des descendants.

Si vous êtes intéressé par la recherche d'ancêtres et de descendants (et que cela vous intéresse plus que de pouvoir facilement mettre à jour les relations), vous pouvez envisager d'ajouter un tableau d'ancêtres à votre deuxième idée pour faciliter également la recherche d'ancêtres et de descendants. Bien sûr, la mise à jour des relations devient une vraie douleur si vous le faites.

Conclusion :

• En fin de compte, tout dépend des actions les plus nécessaires. Étant donné que vous travaillez avec des articles, dont les données sous-jacentes (comme le titre) peuvent changer fréquemment, vous voudrez peut-être éviter la première idée puisque vous auriez besoin de mettre à jour non seulement le document principal de cet article, mais tous les documents enfants ainsi que le parent.

• Votre deuxième idée facilite la récupération du parent immédiat et des enfants. La mise à jour des relations n'est pas non plus trop difficile (c'est certainement mieux que certaines des autres options disponibles).

• Si vous voulez vraiment faciliter la recherche d'ancêtres et de descendants au détriment de la mise à jour des relations aussi facilement, choisissez d'inclure un tableau de références d'ancêtres.

• En général, essayez de minimiser le nombre de parcours requis, car ils nécessitent l'exécution d'une sorte d'itération ou de récursivité pour accéder aux données souhaitées. Si vous appréciez la possibilité de mettre à jour les relations, vous devez également choisir une option qui modifie moins de nœuds dans l'arborescence (les références parentes, les références enfants et votre deuxième idée peuvent le faire).