Comment organiser une relation de plusieurs à plusieurs dans MongoDB ?

Question

J'ai deux tables/collections : Utilisateurs et Groupes. Un utilisateur peut être membre d'un nombre quelconque de groupes et un utilisateur peut également être propriétaire d'un nombre quelconque de groupes. Dans une base de données relationnelle, j'aurais probablement une troisième table appelée UserGroups avec une colonne UserID, une colonne GroupID et une colonne IsOwner.

J'utilise MongoDB et je suis sûr qu'il existe une approche différente pour ce type de relation dans une base de données documentaire. Devrais-je intégrer la liste des groupes et des groupes en tant que propriétaires dans la table Users sous forme de deux tableaux d'ObjectID ? Devrais-je également stocker la liste des membres et des propriétaires dans la table Groups sous forme de deux tableaux, ce qui aurait pour effet d'inverser la relation et d'entraîner une duplication des informations relatives à la relation ?

Ou bien une table UserGroups de transition est-elle un concept légitime dans les bases de données documentaires pour les relations entre plusieurs personnes ?

Merci

Answer 1

Ce que j'ai vu faire, et ce que j'utilise actuellement, ce sont des tableaux intégrés avec des identifiants de nœuds dans chaque document.

Ainsi, le document user1 possède des groupes de propriétés : [id1,id2]

Et le document group1 a la propriété users : [user1]. Le document group2 a également la propriété users : [user1].

De cette façon, vous obtenez un objet Groupe et vous pouvez facilement sélectionner tous les utilisateurs liés, et la même chose pour l'Utilisateur.

Cela demande un peu plus de travail lors de la création et de la mise à jour de l'objet. Lorsque vous dites que deux objets sont liés, vous devez mettre à jour les deux objets.

Il existe également un concept DBReferences dans MongoDB et, en fonction de votre pilote, les objets référencés seront extraits automatiquement lors de la récupération d'un document.

http://www.mongodb.org/display/DOCS/Database+Références#DatabaseReferences-DBRef

Answer 2

Au cas où cela intéresserait quelqu'un, je viens de tomber sur un très bon article publié sur le blog de mongoDB. 6 règles d'or pour la conception de schémas MongoDB . Il y a 3 parties dans cet article, après avoir lu les 3 vous aurez une bonne compréhension.

Answer 3

Je sais que c'est un peu vieux, mais je me pose aussi la question de l'échelle. Que se passe-t-il si vous avez 1000 groupes ?

Answer 4

Comprenons les relations entre plusieurs personnes à l'aide d'exemples.

• des livres aux auteurs
• des étudiants aux enseignants

Les livres aux auteurs sont un de peu à peu de sorte que nous pouvons avoir un tableau de livres ou d'auteurs dans le document d'un autre. Il en va de même pour les étudiants vers les enseignants. Nous pourrions également intégrer au risque de duplication. Cependant, cela nécessitera que chaque élève ait un enseignant dans le système avant l'insertion et vice versa. La logique de l'application peut toujours ne pas le permettre. En d'autres termes, l'objet parent doit exister pour que l'objet enfant existe.

Mais quand vous avez beaucoup à beaucoup utilisez deux collections et créez une véritable liaison.