Esta es una buena pregunta que ilustra los problemas con el exceso de camas y cómo tratarlo.
Ejemplo:Publicar Me gusta
Sigamos con el ejemplo de los usuarios que les gustan las publicaciones, que es un ejemplo simple. Las otras relaciones tendrían que manejarse en consecuencia.
Tienes toda la razón en que almacenar los Me gusta dentro de la publicación tarde o temprano conduciría al problema de que las publicaciones muy populares alcanzarían el límite de tamaño.
Así que correctamente retrocediste para crear un post_likes recopilación. ¿Por qué llamo a esto correcto? ¡Ya que se ajusta a sus casos de uso y requisitos funcionales y no funcionales!
- Se escala indefinidamente (bueno, hay un límite teórico, pero es enorme)
- Es fácil de mantener (cree un índice único sobre
post_idyliked_user_id) y uso (tanto el usuario como la publicación son conocidos, por lo que agregar un Me gusta es una simple inserción o más probablemente una inserción) - Puede averiguar fácilmente a qué usuarios les gusta qué publicación y qué publicación les gusta a qué usuarios
Sin embargo, ampliaría un poco la colección para evitar consultas innecesarias para ciertos casos de uso que son frecuentes.
Supongamos por ahora que los títulos de las publicaciones y los nombres de usuario no se pueden cambiar. En ese caso, el siguiente modelo de datos podría tener más sentido
{
_id: new ObjectId(),
"post_id": someValue,
"post_title": "Cool thing",
"liked_user_id": someUserId,
"user_name": "JoeCool"
}
Ahora supongamos que desea mostrar el nombre de usuario de todos los usuarios a los que les gustó una publicación. Con el modelo anterior, sería una consulta única y bastante rápida:
db.post_likes.find(
{"postId":someValue},
{_id:0,user_name:1}
)
Con solo los ID almacenados, esta tarea bastante habitual necesitaría al menos dos consultas y, dada la restricción de que puede haber un número infinito de personas que gustan de una publicación, potencialmente enorme consumo de memoria (debería almacenar los ID de usuario en la RAM).
Por supuesto, esto conduce a cierta redundancia, pero incluso cuando a millones de personas les gusta una publicación, estamos hablando solo de unos pocos megabytes de espacio en disco relativamente barato (y fácil de escalar) mientras se gana mucho rendimiento. en términos de experiencia de usuario.
Ahora aquí viene la cuestión:incluso si los nombres de usuario y los títulos de las publicaciones están sujetos a cambios, solo tenía que hacer una actualización múltiple:
db.post_likes.update(
{"post_id":someId},
{ $set:{ "post_title":newTitle} },
{ multi: true}
)
Está negociando que toma un tiempo hacer algunas cosas bastante raras, como cambiar un nombre de usuario o una publicación para una velocidad extrema para casos de uso que ocurren con mucha frecuencia.
Conclusión
Tenga en cuenta que MongoDB es una base de datos orientada a documentos. Así que documente los eventos que le interesan con los valores que necesita para consultas futuras y modele sus datos en consecuencia.
