MongoDB, C# y NoRM + Desnormalización

Question

Estoy tratando de usar MongoDB, C# y NoRM para trabajar en algunos proyectos de muestra, pero en este momento me está costando mucho tiempo concentrarme en el modelo de datos. Con los datos relacionados con RDBMS no hay problema. En MongoDB, sin embargo, estoy teniendo dificultades para decidir qué hacer con ellos.

Usemos StackOverflow como ejemplo ... No tengo problemas para entender que la mayoría de los datos en una página de preguntas deben incluirse en un documento. Título, texto de la pregunta, revisiones, comentarios ... todo bien en un objeto del documento.

dónde empezar para obtener nebuloso es sobre la cuestión de los datos del usuario como nombre de usuario, avatar, la reputación (que cambia frecuentemente en especial) ... ¿Te Desnormalizar y actualizar miles de documento registra cada vez que hay un cambio de usuario o ¿de alguna manera vincula los datos entre sí?

¿Cuál es la forma más eficiente de lograr una relación de usuario sin causar toneladas de consultas en cada carga de página? Noté que el tipo DbReference<T> está en NoRM, pero todavía no he encontrado una buena manera de usarlo. ¿Qué sucede si tengo relaciones opcionales anulables?

¡Gracias por tu calificación!

Answer 1

Creo que debe encontrar el equilibrio.

Si yo fuera usted, me limitaría a hacer referencia al ID de usuario en lugar de su nombre/reputación en cada publicación.

Sin embargo, a diferencia de un RDBMS, optaría por incluir los comentarios incrustados en el documento.

Answer 2

¿Por qué quiere evitar la desnormalización y actualizar 'miles de registros de documentos'? Mongodb db diseñado para la desnormalización. Stackoverlow maneja millones de datos diferentes en segundo plano. Y algunos datos pueden estar obsoletos durante un corto período de tiempo y está bien.

Así que la idea principal de lo dicho anteriormente es que debería haber desnormalizado los documentos para mostrarlos rápidamente en la interfaz de usuario.

No se puede consultar por documento referenciado, de ninguna forma que necesite desnormalización.

También sugiero echar un vistazo a la arquitectura cqrs.

Answer 3

Intente investigar cqrs and event sourcing architecture. Esto le permitirá actualizar todos estos datos por cola.

Answer 4

El saldo que he encontrado es el uso de SQL como la base de datos normalizada y Mongo como la copia desnormalizada. Utilizo un ESB para mantenerlos sincronizados entre sí. Utilizo un concepto que llamo "documentos preparados" y "documentos almacenados". Los documentos almacenados son datos que solo se guardan en mongo. Útil para datos que no son relacionales. Los documentos preparados contienen datos que se pueden reconstruir utilizando los datos dentro de la base de datos normalizada. Actúan como memorias caché vivientes de alguna manera: pueden reconstruirse desde cero si los datos alguna vez pierden sincronía (en documentos complicados, este es un proceso costoso porque estos documentos requieren muchas consultas para reconstruirse). También se pueden actualizar un campo a la vez. Aquí es donde entra el bus de servicio. Responde a los eventos enviados después de que se haya actualizado la base de datos normalizada y luego actualiza los documentos mongo preparados relevantes.

Utilice cada base de datos para conocer sus puntos fuertes. Permita que SQL sea la base de datos de escritura que garantiza la integridad de los datos. Deje que Mongo sea la base de datos de solo lectura que funciona a la perfección y puede contener sub documentos para que necesite menos consultas.

** EDIT ** Acabo de volver a leer su pregunta y me di cuenta de lo que en realidad estaba pidiendo. Dejo mi respuesta original en caso de que sea útil.

La forma en que manejaría el ejemplo de Stackoverflow que me dio es almacenar la identificación del usuario en cada comentario. Cargarás la publicación que tendrá todos los comentarios. Esa es una consulta.

A continuación, recorrería los datos de comentario y extraería una matriz de identificadores de usuario que necesita cargar. Luego cárguelos como una consulta por lotes (usando el operador de consulta Q.In()). Eso es dos consultas en total. Luego necesitaría fusionar los datos en una forma final. Existe un equilibrio entre el momento en que debe hacerlo y cuándo usar algo como un ESB para actualizar manualmente cada documento. Use lo que funciona mejor para cada escenario individual de su estructura de datos.