Esto es más un arte que una ciencia. La documentación de Mongo sobre esquemas es una buena referencia, pero aquí hay algunas cosas que debe considerar:
-
Pon todo lo que puedas
La alegría de una base de datos de documentos es que elimina muchas uniones. Su primer instinto debería ser colocar todo lo que pueda en un solo documento. Debido a que los documentos de MongoDB tienen una estructura, y debido a que puede consultar de manera eficiente dentro de esa estructura (esto significa que puede tomar la parte del documento que necesita, por lo que el tamaño del documento no debería preocuparle demasiado) no hay una necesidad inmediata de normalizar datos como lo harías en SQL. En particular, cualquier dato que no sea útil aparte de su documento principal debe ser parte del mismo documento.
-
Separe los datos a los que se puede hacer referencia desde varios lugares en su propia colección.
Esto no es tanto un problema de "espacio de almacenamiento" como un problema de "coherencia de datos". Si muchos registros se refieren a los mismos datos, es más eficiente y menos propenso a errores actualizar un solo registro y mantener referencias a él en otros lugares.
-
Consideraciones sobre el tamaño del documento
MongoDB impone un límite de tamaño de 4 MB (16 MB con 1,8) en un solo documento. En un mundo de GB de datos, esto suena pequeño, pero también son 30 mil tweets o 250 respuestas típicas de desbordamiento de pila o 20 fotos parpadeantes. Por otro lado, esta es mucha más información de la que uno podría querer presentar al mismo tiempo en una página web típica. Primero considere qué facilitará sus consultas. En muchos casos, la preocupación por el tamaño de los documentos será una optimización prematura.
-
Estructuras de datos complejas:
MongoDB puede almacenar estructuras de datos anidadas profundas arbitrarias, pero no puede buscarlas de manera eficiente. Si sus datos forman un árbol, un bosque o un gráfico, necesita almacenar cada nodo y sus bordes en un documento separado. (Tenga en cuenta que hay almacenes de datos diseñados específicamente para este tipo de datos que también se deben considerar)
También se ha señalado que es imposible devolver un subconjunto de elementos en un documento. Si necesita escoger y elegir algunas partes de cada documento, será más fácil separarlas.
-
Coherencia de datos
MongoDB hace un compromiso entre eficiencia y consistencia. La regla es que los cambios en un solo documento son siempre atómico, mientras que nunca se debe suponer que las actualizaciones de varios documentos son atómicas. Tampoco hay forma de "bloquear" un registro en el servidor (puede incorporar esto en la lógica del cliente usando, por ejemplo, un campo de "bloqueo"). Cuando diseñe su esquema, considere cómo mantendrá la consistencia de sus datos. Por lo general, cuanto más guarde en un documento, mejor.
Para lo que está describiendo, incrustaría los comentarios y le daría a cada comentario un campo de identificación con un ObjectID. El ObjectID tiene una marca de tiempo incrustada para que pueda usarla en lugar de crearla si lo desea.
