Vous pouvez éviter le N+1 -problème de centaines de requêtes utilisant $in
-requêtes. Considérez ceci :
Post {
PosterId: ObjectId
Text: string
Comments: [ObjectId, ObjectId, ...] // option 1
}
Comment {
PostId: ObjectId // option 2 (better)
Created: dateTime,
AuthorName: string,
AuthorId: ObjectId,
Text: string
}
Vous pouvez maintenant trouver les commentaires des messages avec un $in requête, et vous pouvez également trouver facilement tous les commentaires faits par un auteur spécifique.
Bien sûr, vous pouvez également stocker les commentaires sous forme de tableau intégré dans la publication et effectuer un $in requête sur les informations de l'utilisateur lorsque vous récupérez les commentaires. De cette façon, vous n'avez pas besoin de dénormaliser les noms d'utilisateur et vous n'avez toujours pas besoin de centaines de requêtes.
Si vous choisissez de dénormaliser les noms d'utilisateur, vous devrez mettre à jour tous les commentaires jamais faits par cet utilisateur lorsqu'un utilisateur change, par ex. son nom. En revanche, si de telles opérations ne se produisent pas très souvent, cela ne devrait pas être grave. Ou peut-être est-il encore préférable de stocker le nom que l'utilisateur avait lorsqu'il a fait le commentaire, en fonction de vos besoins.
Un problème général avec l'intégration est que différents auteurs écriront sur le même objet
, vous devrez donc utiliser les modificateurs atomiques
(comme $push ). C'est parfois plus difficile à utiliser avec les mappeurs (je ne connais pas la mongoalchimie), et généralement moins flexible.
