Puedes evitar el N+1 -problema de cientos de solicitudes usando $in
-consultas. Considere esto:
Post {
PosterId: ObjectId
Text: string
Comments: [ObjectId, ObjectId, ...] // option 1
}
Comment {
PostId: ObjectId // option 2 (better)
Created: dateTime,
AuthorName: string,
AuthorId: ObjectId,
Text: string
}
Ahora puedes encontrar los comentarios de las publicaciones con un $in consulta, y también puede encontrar fácilmente todos los comentarios realizados por un autor específico.
Por supuesto, también puede almacenar los comentarios como una matriz incrustada en la publicación y realizar un $in Consulta sobre la información del usuario cuando obtienes los comentarios. De esa manera, no necesita desnormalizar los nombres de usuario y tampoco necesita cientos de consultas.
Si elige desnormalizar los nombres de usuario, tendrá que actualizar todos los comentarios que haya hecho ese usuario cuando un usuario cambie, p. su nombre. Por otro lado, si tales operaciones no ocurren con mucha frecuencia, no debería ser un gran problema. O tal vez sea incluso mejor almacenar el nombre que tenía el usuario cuando hizo el comentario, según sus requisitos.
Un problema general con la incrustación es que diferentes escritores escribirán en el mismo objeto
, por lo que tendrá que usar los modificadores atómicos
(como $push ). A veces, esto es más difícil de usar con los mapeadores (aunque no sé Mongoalchemy) y, en general, menos flexible.
