Relaciones de MongoDB para objetos

Question

Disculpe mi inglés, todavía estoy intentando dominarlo.

Comencé a aprender MongoDB (viniendo de un fondo C#) y me gusta la idea de qué es MongoDB. Tengo algunos problemas con ejemplos en internet.

Tome la publicación de blog popular/ejemplo de comentarios. La publicación tiene ninguno o muchos comentarios asociados a ella. Creo el objeto Post, agrego algunos objetos de Comentario al IList en Publicar. Esta bien.

¿Lo agrego solo a una colección de "Publicaciones" en MonoDB o debería tener dos colecciones, una es blog.posts y blog.posts.comments?

Tengo un modelo de objeto bastante complicado, la manera más fácil de pensarlo es como un sistema bancario: el nuestro es la minería. Traté de resaltar las tablas con corchetes.

[Usuarios] tener uno o muchos [Cuentas] que tienen uno o muchos [transacciones] que tiene una y sólo una [Tipo]. [Transacciones] puede tener uno o más [Etiqueta] asignados a la transacción. [Usuarios] crean sus propias [Etiquetas] exclusivas de esa cuenta de usuario y en ocasiones necesitamos ofrecer informes por esas etiquetas (Ej. Para mayo, perforación de etiqueta-gasto fue $ 123456.78).

Para indexar, habría pensado que separarlos sería bueno, pero me preocupa que sea una mala práctica pensar en los viejos días de RBDMS.

En cierto modo, es como el ejemplo del blog. No estoy seguro de si debería tener 1 [Cuenta] Colección y conservar toda la información allí, o tener un paso intermedio que la divida en colecciones separadas.

La otra consulta relacionada es que, cuando persiste de un lado a otro, ¿por lo general vuelve todo asociado con ese registro, incluso si no es necesario o lo limita?

Answer 1

Depende.

Depende de la cantidad de cada uno de estos tipos de objetos que esperas tener. ¿Puedes incluirlos a todos en un solo documento MongoDB para un usuario dado? Probablemente no.

Depende de las relaciones: ¿es usuario? ¿Cuenta una relación de uno a muchos o varios a muchos? Si es uno para muchos y la cantidad de cuentas es pequeña, puede optar por ponerlos en un IList en un documento de usuario.

Aún puede modelar las relaciones en MongoDB con colecciones separadas PERO no hay uniones en la base de datos, por lo que tiene que hacer eso en el código. Cargar un usuario y luego cargar sus cuentas podría estar bien desde una perspectiva de rendimiento.

Puede indexar matrices INTO en documentos. No piense en un índice simplemente como un índice en un campo simple en un documento (como SQL). Puede usar, por ejemplo, una colección de etiquetas en un documento e indexar en las etiquetas. (Consulte http://www.mongodb.org/display/DOCS/Indexes#Indexes-Arrays)

Cuando recupera o escribe datos, puede realizar una lectura parcial y una escritura parcial de cualquier documento.(Consulte http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields)

Y, finalmente, cuando no puede ver cómo obtener lo que desea utilizando colecciones e índices, es posible que pueda lograrlo utilizando map reduce. Por ejemplo, para encontrar todas las etiquetas actualmente en uso ordenadas por su frecuencia de uso, map cada documento que emite las etiquetas utilizadas en él, y luego reduce para obtener el resultado que desee. A continuación, puede almacenar el resultado de ese mapa reducir de forma permanente y solo actualizarlo cuando lo necesite.

Una preocupación adicional: menciona el cálculo de totales por etiqueta. Si desea una coherencia transaccional con calidad de contabilidad, es posible que MongoDB no sea la opción correcta para usted. "Congruencia eventual" es el nombre del juego para las tiendas de datos NoSQL y generalmente no son aptos para las transacciones financieras. Por ejemplo, no importa si un usuario ve una publicación de blog con 3 comentarios, mientras que otra ve 4 porque acierta en copias de réplicas diferentes que todavía no están sincronizadas, pero para un informe financiero, ese tipo de consistencia sí importa: su informe puede no sumar!