Compartir
Publicidad

NoSQL y Relaciones

NoSQL y Relaciones
0 Comentarios
Publicidad
Publicidad

Poco a poco las bases de datos NoSQL tipo MongoDB se van haciendo un hueco en el mercado. Son bases de datos orientadas al concepto de documento. Un documento no es ni más ni menos que un conjunto de entidades de bases de datos agrupados como una “gran” entidad. Por ejemplo podríamos tener los conceptos de Persona, Historial Médico y Compra que en un diagrama entidad relación crearían las siguientes tres tablas independientes.

modeloer.png

En cambio en una base de datos orientada a documentos estos tres conceptos pueden ser agrupados bajo un tipo de documento al que denominamos Persona.

documento-1.png

La verdad es que la solución es muy sencilla y acelerará las búsquedas etc. El problema es que este tipo de modelos es muy válido para estructuras pequeñas en el que un tipo de documento o dos nos resuelven todos nuestros problemas. El día a día del trabajo no suele ser tan sencillo y junto al Historial Médico y la Compra aparecerán nuevos conceptos como por ejemplo Cita Médica o Dirección del Paciente etc. Es evidente que no todo se puede ubicar en el mismo documento y es ahí donde comienzan las dudas y los problemas.

varios.png

Persona y Modelo

El modelo que tenemos es muy sencillo pero incluso él admite varias configuraciones como documento.

a) Un único documento con los tres conceptos dentro de él.

b) Tres documentos independientes cada uno de ellos referenciando a los demás.

c)Un documento con Persona e Historial Médico referenciando a las Compras.

¿Cuál de estas tres opciones elegimos?

Aquí como vemos ya no es un sitio en el que podamos aplicar las reglas de normalización clásicas sino que nos encontramos un problema nuevo que tenemos que abordar.

Relaciones Uno a Uno

En las relaciones uno a uno el consejo más habitual es que esa relación quede construida dentro de un mismo documento (relación embebida).

Relaciones Uno a Muchos

Esta quizás es la relación más delicada ya que de entrada las dos opciones parecen igual de buenas. Puedo asociar todo a un único documento (relación embebida) en donde la Persona lo almacena todo o puedo dividir el modelo en dos partes. Por un lado una Persona que incluye su Historial y por otro una referencia al documento de la Compra. ¿Cuál es mejor?.

La respuesta es que “depende” y sobre todo depende mucho de que relaciones tenga el concepto de Compra con otros documentos de la base de datos. Si la respuesta es que no tiene relaciones con nadie más optaremos por que todo esté en el mismo documento.

comprasola.png

En cambio si la Compra esta relacionada de forma fuerte con otros conceptos del negocio optaremos normalmente por una relación de referencia.

compravarios.png

En Genbeta Dev | MongoDB. Qué es,cómo funciona
En Genbeta Dev | MongoDB: empezando por el principio. Insertando datos

Temas
Publicidad
Comentarios cerrados
Publicidad
Publicidad
Inicio