El ejemplo que das, al igual que la mayoría de los ejemplos del mundo real de relaciones de muchos a muchos, es en realidad un ejemplo de pocos a pocos relación. Es posible que tenga muchos restaurantes y muchos comensales pero, en comparación con todo el conjunto, cualquier restaurante dado solo ha servido a un pequeño subconjunto de comensales y la mayoría de los comensales individuales solo habrán visitado un pequeño subconjunto de los restaurantes. Suena como una red escasamente enlazada donde la relación de densidad de enlaces es significativamente inferior a uno.
Sin embargo, usted preguntó acerca de muchos a muchos, entonces, ¿qué tal si usamos una red neuronal como ejemplo? Las redes neuronales a menudo forman redes densas y, por lo tanto, representan una verdadera red de muchos a muchos. En cuyo caso, la respuesta es fácil:no use mongoDB. Utilice estructuras personalizadas y estrategias de serialización adaptadas a sus requisitos específicos. Después de todo, las verdaderas relaciones de muchos a muchos son casi siempre atípicas y, por lo tanto, justifican un tratamiento específico.
Dicho esto, modelar el más habitual pocos a pocos La relación en mongoDB se puede lograr sin sacrificar la rica estructura del documento, y la forma en que lo logra depende de sus patrones de acceso.
Por lo tanto, con el ejemplo de la red restaurante/cena, si normalmente va a consultar un restaurante sobre sus comensales, entonces crearía una matriz de diner_ids con cada restaurante. La otra forma significaría una matriz de restaurant_ids con cada comensal. Ambos para la capacidad de consulta bidireccional.
Se debe tener cuidado porque no existe una restricción de clave externa en mongoDB y, por lo tanto, mantener la integridad referencial de sus datos es su responsabilidad.
Si el rendimiento es lo más importante para usted, es posible que desee incrustar los datos en cada documento en lugar de hacer referencia a ellos con una identificación. Esta es la opción de mayor rendimiento para lectura (no tanto para escritura) ya que todos los datos se pueden extraer del disco de una sola vez. Significa que deberá trabajar más cuando actualice los valores de los datos para garantizar la integridad de sus datos, pero a menudo esto no es tan aterrador como parece al principio. ¿Con qué frecuencia los comensales realmente cambian sus nombres? Y dependiendo de los tamaños de los documentos, es posible que no necesariamente desee incrustar el documento completo, un subconjunto de los datos más una identificación para apuntar al registro completo a menudo hará el truco.
En resumen, el diseño del esquema mongoDB debe estar impulsado por los requisitos de la aplicación. Diferentes esquemas para diferentes aplicaciones en lugar de una base de datos relacional monolítica para gobernarlas a todas. ¿Cuál es la realidad de los datos? ¿Cómo utiliza realmente la aplicación estos datos? ¿Qué tamaño tienen los objetos del documento que se almacenan? Responda estas preguntas y su esquema prácticamente se diseñará solo.
