Normalización MongoDB, clave externa y unión

Question

Antes de sumergirme profundamente en MongoDB durante días, pensé que podría hacer una pregunta bastante básica sobre si debería profundizar en ella o no. Básicamente no tengo experiencia con nosql.

He leído un poco acerca de algunos de los beneficios de las bases de datos de documentos, y creo que para esta nueva aplicación, serán realmente geniales. Siempre es una molestia hacer favoritos, comentarios, etc. para muchos tipos de objetos (muchas relaciones m-to-m) y subclases, es un poco difícil de manejar.

También tengo una estructura que será difícil de definir en SQL porque está muy anidada y se traduce a un documento mucho mejor que 15 tablas diferentes.

Pero estoy confundido acerca de algunas cosas.

1. ¿Es deseable mantener su base de datos normalizada todavía? Realmente no quiero actualizar múltiples registros. ¿Sigue así cómo se acercan las personas al diseño de la base de datos en MongoDB?

2. ¿Qué sucede cuando un usuario prefiere un libro y esta selección todavía se almacena en un documento de usuario, pero luego se borra el libro? ¿Cómo se separa la relación sin claves externas? ¿Soy responsable manualmente de eliminar todos los enlaces por mi cuenta?

3. ¿Qué sucede si un usuario ha preferido un libro que ya no existe y lo consulto (algún tipo de unión)? ¿Tengo que hacer alguna tolerancia a fallas aquí?

Answer 1

MongoDB no es compatible con las relaciones de claves foráneas del lado del servidor, la normalización también se desaconseja. Debería incrustar su objeto hijo dentro de los objetos principales si es posible, esto aumentará el rendimiento y hará que las claves externas sean totalmente innecesarias. Dicho esto, no siempre es posible, por lo que existe una construcción especial llamada DBRef que permite referenciar objetos en una colección diferente. Esto puede ser entonces no tan rápido porque DB tiene que realizar consultas adicionales para leer objetos pero permite el tipo de referencia de clave externa.

Aún así tendrá que manejar sus referencias manualmente. Solo mientras busca su DBRef verá si existe, el DB no revisará todos los documentos para buscar las referencias y las eliminará si el objetivo de la referencia ya no existe. Pero creo que eliminar todas las referencias después de eliminar el libro requeriría una única consulta por colección, no más, por lo que no es realmente difícil.

Si su esquema es más complejo, entonces probablemente debería elegir una base de datos relacional y no nosql.

También hay un libro sobre el diseño de bases de datos MongoDB: Document Design for MongoDB

ACTUALIZACIÓN El libro anterior ya no está disponible, sin embargo, debido a la popularidad de MongoDB hay un buen montón de otros. No los vincularé a todos, ya que es probable que esos enlaces cambien, una simple búsqueda en Amazon muestra varias páginas, por lo que no debería ser un problema encontrarlas.

Consulte la página del manual para MongoDB 'Manual references' and DBRefs para obtener más detalles y ejemplos

Answer 2

arriba, @TomaaszStanczak afirma

MongoDB no soporta relaciones de clave externa del lado del servidor, también se desaconseja normalización. Debería incrustar su objeto hijo dentro de los objetos principales si es posible, esto aumentará el rendimiento y hacer que las claves foráneas sean totalmente innecesarias. Dicho esto, no siempre es posible ...

Mongo no desaconseja la normalización. Para ser claros, estamos hablando de dos tipos de relaciones fundamentalmente diferentes que dos entidades de datos pueden tener. En una, una entidad secundaria es propiedad exclusivamente por un objeto primario. En este tipo de relación, el modo Mongo es incrustar.

En la otra clase de relación existen dos entidades de forma independiente: tienen vidas y relaciones de vida independientes. Mongo desea que este tipo de relación no exista y guarde un frustrante silencio sobre cómo lidiar con eso. Incrustar no es una solución. La normalización no se desaconseja ni se fomenta. Mongo solo te da dos mecanismos para lidiar con eso; Manual refs (análogo a una clave con la restricción de clave foránea que vincula dos tablas), y DBRef (una forma diferente, ligeramente más estructurada de hacer lo mismo). En este caso de uso, las bases de datos SQL ganan.