En este nuevo artículo comenzaremos a ver estrategias de modelado de colecciones en MongoDB. Como ya sabemos ya no existen tuplas ni tablas, ahora trabajamos con documentos y colecciones, pero en MongoDB existen distintas estrategias que nos ayudarán a diseñar una base de datos óptima para nuestras aplicaciones web dependiendo de las consultas más frecuentes con la que atacaremos a nuestra base de datos.

Mongodb-database

Esquema Flexible

Como recordamos MongoDB tiene un esquema flexible, donde las colecciones no fuerzan una estructura idéntica para todos los documentos. Esto significa que los documentos de la misma coleccion no necesitan tener el mismo numero de campos o estructura, y los campos comunes pueden contener diferentes tipos de datos. Cada documento solo necesita contener un numero relevante de campos de la entidad u objeto que el documento representa. Por ejemplo pueden existir distintos tipos de usuarios en una aplicación, donde un cliente necesita información personal, mientras que un administrador le basta con los credenciales.

En la práctica la mayoria de los documentos de una colección comparte una estructura similar, pero la flexibilidad del esquema nos aporta una capacidad de modelación de los documentos acercándonos a reflejar los niveles de modelo de la aplicación

Aplicaciones Cambiantes y Escalables

Como en todos los modelos de datos, al realizar el diseño de modelado para MongoDB hay que tener en cuenta las propiedades inherentes y los requisitos de los objetos de la aplicación además de las relaciones entre los objetos de ésta. MongoDB  también debe reflejar todas estas características.

Cuando pasa el tiempo, la cantidad de datos de la aplicaron va a crecer y ser cambiante lo que implica que se van a definir los tipos de consultas que la aplicación va a requerir. Estas consideraciones y requisitos hacen tomar decisones a los desarrolladores en los modelos de datos normalizando o desnormalizando Colecciones. Estas decisiones implica que en el modelo de datos se almacene la información en un único documento o sin embargo este documento debe describir relaciones empleando relaciones entre documentos.

Decisiones de Modelado:

Las decisiones para el modelado de los datos implica determinar como se debe estructurar los documentos para ganar en eficiencia. Una de las decisiones primordial es cuando debemos de emplear documentos embebidos o referencias a otros documentos

Embedding

Esta decisión implica la desnormalización de los datos, almacenando dos documentos relacionados en un único documento. Las operaciones a este documento son mucho menos costosas para el servidor que las operaciones que involucran múltiples documentos. En general, se debe de emplear este modelo cuando se tienen relaciones del tipo “contiene” entre entidades. Básicamente en relaciones Uno a Uno.

En este ejemplo vemos como el documento dirección se encuentra embebido en el documento usuario

{
	"_id":ObjectId("514ed98d44aee1b035ee756f"),
	"nombre":"Adrian",
	"apellido":"Alonso",
	"numerodecontacto":"412312",
	"direccion":
		{
		"tipo":"Calle",
		"nombre":"Buenavista",
		"numero":2,
		"piso": Noveno B,
		"codigopostal":28823
		},
	"email":"prueba@email.com",
	"password":"example",
	"privilegios":0
}

Relaciones Entre Documentos

Este tipo de decisiones se deben de tomar cuando se tienen relaciones Uno a Muchos donde la parte de muchos siempre aparecen o son visionados desde el contexto de sus documentos padres. Por ejemplo en el siguiente ejemplo podemos ver una referencia entre documentos entre la colección Producto y Comentarios del producto. En este caso merece la pena llevar a los comentarios en una nueva colección en vez de embeberlos si los comentarios van a ser referenciados y filtrados por usuario si ese tipo de consultas se requirieren en gran cantidad en la aplicación. Este ejemplo ya nos llevaría a una decisión de modelo.

Sin embargo la referencia Usuario con Comentario se ve claramente que debe ser una referencia entre documentos, ya que el Usuario puede cambiar sus datos en cualquier momento sin que el Comentario se de cuenta, por lo que es importante enlazarlos con una relación aunque perdamos un nivel de indirección a la hora de consultar.

{
	"_id": ObjectId("514d920b44ae16d201a3ff51),
	"nombre":"Capucchino",
	"precio":20,
	"marca":"Nescafé",
	"comentarios":
		[
			DBRef("Comentario",
			ObjectId("514d91a644ae16d201a3ff50"))
		]
}

{
	"_id" : ObjectId("514d91a644ae16d201a3ff50"),
	"usuario" : DBRef("Usuario", ObjectId("514ed98d44aee1b035ee756f")),
	"texto" : "Me gusta"
}

Conclusión

Este nuevo mundo de bases de datos NoSQL nos abre nuevos problemas a solucionar a la hora de modelar, tomar decisiones en el modelo de datos para ganar en eficiencia. Ya sabemos las ventajas que nos aporta, por lo tanto en este proceso es cuando debemos de aprovechar sus características para diseñar el modelo de datos mas apropiado para nuestra aplicación

Artículos relacionados...

Sobre El Autor

Coordinador en AnalyticaWeb.com Me encanta el SEO y la Analítica Web. Emprendedor y autodidacta que con pasión intenta alcanzar los máximos de su proyección. Disfruto convirtiendo datos en negocio.

Artículos Relacionados

2 Respuestas

  1. Yeraldo

    Es estoy usando Hibernate y JPA con MongoDB, mi duda es ¿Es recomendables usar una sequencia o counter para generar el ID o es mejor usar el ObjectId que genera MongoDB? ¿El usar secuencias alenta a Mongo? ¿Podemos correr el riesgo de tener un id duplicado con la secuenci?

    Responder

Hacer Comentario

Su dirección de correo electrónico no será publicada.