Cela dépend.
Cela dépend du nombre de chacun de ces types d'objets que vous vous attendez à avoir. Pouvez-vous tous les intégrer dans un seul document MongoDB pour un sujet donné ? Probablement pas.
Cela dépend des relations - avez-vous des relations un-à-plusieurs ou plusieurs-à-plusieurs ? S'il s'agit d'un à plusieurs et que le nombre d'entités associées est faible, vous pouvez choisir de les incorporer dans une IList sur un document. S'il s'agit de plusieurs à plusieurs, vous pouvez choisir d'utiliser une relation plus traditionnelle ou vous pouvez choisir d'intégrer les deux côtés en tant que ILists.
Vous pouvez toujours modéliser des relations dans MongoDB avec des collections séparées MAIS il n'y a pas de jointure dans la base de données, vous devez donc le faire dans le code. Charger un sujet, puis charger les commentaires correspondants peut être très bien du point de vue des performances.
Autres conseils :
Avec MongoDB, vous pouvez indexer des tableaux INTO sur des documents. Ne pensez donc pas à un index comme étant simplement un index sur un simple champ d'un document (comme SQL). Vous pouvez utiliser, par exemple, une collection de balises sur un sujet et indexer les balises. (Voir http://www.mongodb.org/display/DOCS/Indexes #Index-Tableaux )
Lorsque vous récupérez ou écrivez des données, vous pouvez effectuer une lecture partielle et une écriture partielle de n'importe quel document. (voir http://www.mongodb.org/display /DOCS/Récupération+d'un+sous-ensemble+de+champs )
Et, enfin, lorsque vous ne voyez pas comment obtenir ce que vous voulez en utilisant des collections et des index, vous pourrez peut-être y parvenir en utilisant map reduce. Par exemple, pour trouver toutes les balises actuellement utilisées triées par leur fréquence d'utilisation, vous mappez chaque sujet émettant les balises utilisées, puis vous réduisez cet ensemble pour obtenir le résultat souhaité. Vous pouvez ensuite stocker le résultat de cette réduction de carte de manière permanente et ne le mettre à jour que lorsque vous en avez besoin.
C'est un changement d'esprit assez important par rapport à la pensée relationnelle, mais cela en vaut la peine si vous avez besoin de l'évolutivité et de la flexibilité qu'apporte une approche NOSQL.
