C'est plus un art qu'une science. La documentation Mongo sur les schémas est une bonne référence, mais voici quelques éléments à prendre en compte :
-
Mettez-en autant que possible
La joie d'une base de données de documents est qu'elle élimine de nombreuses jointures. Votre premier réflexe devrait être de placer autant que possible dans un seul document. Parce que les documents MongoDB ont une structure, et parce que vous pouvez interroger efficacement au sein de cette structure (cela signifie que vous pouvez prendre la partie du document dont vous avez besoin, donc la taille du document ne devrait pas vous inquiéter beaucoup), il n'y a pas besoin immédiat de normaliser des données comme vous le feriez en SQL. En particulier, toute donnée qui n'est pas utile en dehors de son document parent doit faire partie du même document.
-
Séparez les données auxquelles il est possible de se référer à partir de plusieurs endroits dans sa propre collection.
Il ne s'agit pas tant d'un problème "d'espace de stockage" que d'un problème de "cohérence des données". Si de nombreux enregistrements font référence aux mêmes données, il est plus efficace et moins sujet aux erreurs de mettre à jour un seul enregistrement et d'en conserver les références à d'autres endroits.
-
Considérations relatives à la taille du document
MongoDB impose une limite de taille de 4 Mo (16 Mo avec 1,8) sur un seul document. Dans un monde de Go de données, cela semble petit, mais c'est aussi 30 000 tweets ou 250 réponses Stack Overflow typiques ou 20 photos scintillantes. D'un autre côté, il s'agit de bien plus d'informations que l'on pourrait vouloir présenter en même temps sur une page Web typique. Considérez d'abord ce qui facilitera vos requêtes. Dans de nombreux cas, le souci de la taille des documents sera une optimisation prématurée.
-
Structures de données complexes :
MongoDB peut stocker des structures de données imbriquées en profondeur arbitraires, mais ne peut pas les rechercher efficacement. Si vos données forment un arbre, une forêt ou un graphique, vous devez effectivement stocker chaque nœud et ses bords dans un document séparé. (Notez qu'il existe des magasins de données spécialement conçus pour ce type de données qu'il convient également de prendre en compte)
Il a également été souligné qu'il est impossible de retourner un sous-ensemble d'éléments dans un document. Si vous devez choisir quelques éléments de chaque document, il sera plus facile de les séparer.
-
Cohérence des données
MongoDB fait un compromis entre efficacité et cohérence. La règle est que les modifications apportées à un seul document sont toujours atomiques, tandis que les mises à jour de plusieurs documents ne doivent jamais être supposées être atomiques. Il n'y a également aucun moyen de "verrouiller" un enregistrement sur le serveur (vous pouvez intégrer cela dans la logique du client en utilisant par exemple un champ "verrouiller"). Lorsque vous concevez votre schéma, réfléchissez à la manière dont vous assurerez la cohérence de vos données. Généralement, plus vous en conservez dans un document, mieux c'est.
Pour ce que vous décrivez, j'intégrerais les commentaires et donnerais à chaque commentaire un champ d'identification avec un ObjectID. L'ObjectID a un horodatage intégré afin que vous puissiez l'utiliser au lieu d'être créé à si vous le souhaitez.
