básico NoSQL cuestión de diseño de documentos

Question

Estoy tratando de encontrar la mejor manera de implementar este sistema para mi ... y obtener mi cabeza fuera del espacio RDBMS por ahora ...

Una parte de mi actual DB tiene tres tablas: Show, ShowEntry y Entry. Básicamente, ShowEntry es una tabla de unión muchos-a-muchos entre Show y Entry. En mi RDBMS creo que es bastante lógico, ya que cualquier cambio en los detalles de Show se puede hacer en un solo lugar, y lo mismo con Entry.

¿Cuál es la mejor manera de reflejar esto en un almacenamiento basado en documentos? Estoy seguro de que no hay una sola forma de hacerlo, pero no puedo evitar pensar si el almacenamiento basado en documentos es apropiado para este caso.

Para su información, actualmente estoy considerando implementar RavenDB. Si bien las discusiones sobre el diseño general de NoSQL serán buenas, ¡una más centrada en RavenDB será fantástica!

Gracias, D.

Answer 1

Al modelar una relación de varios a varios en una base de datos de documento, generalmente almacena una colección de claves foráneas en solo uno de los documentos. El documento que elijas depende en gran medida de la dirección en la que pretendas atravesar la relación. Atravesarlo de una manera es trivial, atravesarlo de otra manera requiere un índice.

Tome el ejemplo de la cesta de la compra. Es más importante saber exactamente qué artículos están en una cesta en particular que qué cestas contienen un artículo en particular. Dado que normalmente seguimos la relación en la dirección de la cesta al artículo, tiene más sentido almacenar ID de artículo en una cesta que guardar las ID de la cesta en un artículo.

Aún puede recorrer la relación en la dirección opuesta (por ejemplo, buscar canastas que contengan un artículo en particular) usando un índice, pero el índice se actualizará en segundo plano para que no siempre sea 100% exacto. (Puede esperar a que el índice sea preciso con WaitForNonStaleResults, pero ese retraso se mostrará en su UI)

Si necesita una precisión del 100% inmediata en ambas direcciones, puede almacenar claves externas en ambos documentos, pero su aplicación tendrá que actualizar dos documentos cada vez que se crea o destruye una relación.

Answer 2

This fue un largo camino hacia la solución de mi pregunta!