Diseño de esquema de base de datos Mongodb con datos compartidos

Tu desafío proviene del hecho de que Prop_Info debe ser recuperado por ambas consultas. Esto hace que sea difícil determinar en qué colección de Mongo debería vivir.

En MongoDB, crea el esquema de su documento con el objetivo ideal de que un solo documento tenga toda la información que necesita según sus patrones de consulta. En el caso de que necesite tener los mismos datos D (como Prop_Info en su caso) devuelto por dos consultas separadas contra dos colecciones separadas A y B , tienes que elegir entre las siguientes tres estrategias:

1. Duplicar D en los documentos de ambos A y B y hacer cumplir la coherencia con su código. Esta suele ser la elección de diseño de los sistemas de alto rendimiento que desean eliminar la necesidad de una segunda consulta, incluso si eso conlleva el costo de la complejidad adicional del código en el lado de inserción/actualización y con algunos problemas potenciales de coherencia, ya que Mongo no es ACID.

2. Poner D en A y almacenar una referencia (DBRef o alguna otra combinación de campos de identificación) en B para que pueda llegar a él con una segunda consulta. Esta suele ser la opción de diseño cuando el número de consultas a A supera el número de consultas a B . Mantiene D local a la colección consultada con más frecuencia. En este patrón de diseño de esquema, solo necesita realizar una segunda consulta cuando consulta B .

3. Poner D en una nueva colección C y realice una segunda consulta desde ambos A y B . Esta suele ser la opción de diseño frente a requisitos futuros muy inciertos en los que no está claro cuáles serían las compensaciones si elige (1) o (2) arriba. Es el esquema más "relacional" y el que te obligará a realizar una segunda consulta cuando consultas tanto A y B .

La estrategia que elija depende de su dominio, los patrones de consulta, el soporte que obtiene de su marco de mapeo relacional de objetos (ORM) (si usa uno) y, por último, pero no menos importante, su preferencia.

En las situaciones que me he encontrado, nunca he elegido (3). He usado (1) en situaciones de alto rendimiento (sistemas de análisis). He usado (2) en todos los demás lugares, ya que los patrones de acceso a las consultas han dejado claro dónde deben residir los datos "compartidos".

Una vez que elija su estrategia, si aún necesita ayuda, publique otra pregunta SO que se centre específicamente en el problema de diseño del esquema dada la estrategia elegida.

Tres consejos finales:

1. Si los datos compartidos D tiene una multiplicidad de relación mayor que 1 use una matriz. Puede indexar arreglos completos y puede consultar con precisión dentro de los arreglos usando $elemMatch .

2. Para actualizar D en la estrategia (1) o (2) use el modificador atómico de MongoDB operaciones , muchos de los cuales están diseñados para operar en arreglos.

3. Esta pregunta SO cubre el patrón de dos consultas DBRef en la respuesta de @Stennie. (@Stennie trabaja para 10gen, los marcadores de MongoDB.)

¡Buena suerte!