Conception de schéma de base de données Mongodb avec données partagées

Votre défi vient du fait que Prop_Info doit être récupéré par les deux requêtes. Il est donc difficile de déterminer dans quelle collection Mongo il devrait vivre.

Dans MongoDB, vous créez votre schéma de document dans le but idéal qu'un seul document contienne toutes les informations dont vous avez besoin compte tenu de vos modèles de requête. Dans le cas où vous avez besoin d'avoir les mêmes données D (comme Prop_Info dans votre cas) renvoyé par deux requêtes distinctes sur deux collections distinctes A et B , vous devez choisir entre les trois stratégies suivantes :

1. D dupliqué dans les documents des deux A et B , et appliquez la cohérence avec votre code. C'est généralement le choix de conception des systèmes hautes performances qui souhaitent éliminer le besoin d'une deuxième requête, même si cela se fait au prix d'une complexité de code supplémentaire du côté de l'insertion/de la mise à jour et avec des problèmes de cohérence potentiels puisque Mongo n'est pas ACID.

2. Mettez D en A et stocker une référence (DBRef ou une autre combinaison de champs d'identification) dans B afin que vous puissiez y accéder avec une deuxième requête. C'est généralement le choix de conception lorsque le nombre de requêtes à A dépasse le nombre de requêtes à B . Il conserve D local à la collection la plus fréquemment interrogée. Dans ce modèle de conception de schéma, vous n'avez qu'à faire une deuxième requête lorsque vous interrogez B .

3. Mettez D dans une nouvelle collection C et faites une deuxième requête à partir des deux A et B . C'est généralement le choix de conception face à des exigences futures très incertaines où il n'est pas clair quels seraient les compromis si vous optiez pour (1) ou (2) ci-dessus. C'est le schéma le plus "relationnel" et celui qui vous obligera à faire une deuxième requête lorsque vous interrogerez les deux A et B .

La stratégie que vous choisissez dépend de votre domaine, des modèles de requête, du support que vous obtenez de votre framework de mappage objet-relationnel (ORM) (si vous en utilisez un) et, enfin et surtout, de votre préférence.

Dans les situations que j'ai rencontrées, je n'ai jamais choisi (3). J'ai utilisé (1) dans des situations de haute performance (systèmes d'analyse). J'ai utilisé (2) partout ailleurs car les modèles d'accès aux requêtes ont rendu évident l'emplacement des données "partagées".

Une fois que vous avez choisi votre stratégie, si vous avez encore besoin d'aide, postez une autre question SO qui se concentre spécifiquement sur le problème de conception de schéma compte tenu de la stratégie choisie.

Trois derniers conseils :

1. Si les données partagées D a une multiplicité de relation supérieure à 1 utiliser un tableau. Vous pouvez indexer des tableaux entiers et interroger précisément l'intérieur des tableaux en utilisant $elemMatch .

2. Pour mettre à jour D dans la stratégie (1) ou (2), utilisez le modificateur atomique de MongoDB opérations , dont beaucoup sont conçus pour fonctionner sur des baies.

3. Cette question SO couvre le modèle de requête DBRef two dans la réponse de @ Stennie. (@Stennie travaille pour 10gen, les marqueurs de MongoDB.)

Bonne chance!