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 nuestra base de datos.

Esquema Flexible con MongoDb

Como recordamos MongoDB tiene un esquema flexible, donde las colecciones no fuerzan tener 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. 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 solo le basta con los datos 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 modelado de los documentos independiente.

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 aplicación va a crecer y sera 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 implican que el modelo de datos almacene la información en un único documento o sin embargo este documento deba poseer relaciones con otros documentos.

Decisiones de Modelado en MongoDb

Las decisiones para el modelado de los datos implica determinar como se debe estructurar los documentos para ganar en eficiencia. Una de las decisiones primordiales es saber cuando debemos de emplear documentos embebidos o cuando 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