Ça 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 utilisateur donné ? Probablement pas.
Cela dépend des relations - l'utilisateur-compte est-il une relation un-à-plusieurs ou plusieurs-à-plusieurs ? S'il s'agit d'un à plusieurs et que le nombre de comptes est faible, vous pouvez choisir de les placer dans une IList sur un document utilisateur.
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 utilisateur, puis charger ses comptes peut être très bien du point de vue des performances.
Vous pouvez indexer des tableaux INTO sur des documents. Ne considérez 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 document 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 devez mapper chaque document émettant les balises qui y sont 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.
Une autre préoccupation :vous mentionnez le calcul des totaux par tag. Si vous souhaitez une cohérence transactionnelle de qualité comptable, MongoDB n'est peut-être pas le bon choix pour vous. "Eventual-cohérence" est le nom du jeu pour les magasins de données NoSQL et ils ne conviennent généralement pas aux transactions financières. Par exemple, cela n'a pas d'importance si un utilisateur voit un article de blog avec 3 commentaires tandis qu'un autre en voit 4 parce qu'il a atteint différentes répliques qui ne sont pas encore synchronisées, mais pour un rapport financier, ce type de cohérence est important - votre le rapport peut ne pas correspondre !
