Con la popularidad de las bases de datos NoSQL se hacen necesarias unas nuevas normas y recomendaciones sobre el modelado de datos, veamos las principales consideraciones sobre una de las principales y más utilizadas bases de datos NoSQL: MongoDB.

Como sabemos los datos en MongoDB tienen un esquema flexible, tanto que las Colecciones no deben seguir una estructura de documento, o dicho de otra forma documentos en la misma colección no tienen que tener la misma estructura e incluso campos comunes pueden ser de diferente tipo.

Como en cualquier modelado con MongoDB se deben tener en cuenta:

• Propiedades de las colecciones
• Relaciones entre los objetos de la aplicación
• Cómo crecen y cambian los datos con el tiempo
• Qué tipo de queries tendrá la aplicación

Lo que lleva a tomar ciertas decisiones a la hora de modelar los datos (ya que modelos de datos equivalentes pueden sin embargo afectar al rendimiento), como:

• Normalización y denormalización: Los modelos de datos totalmente normalizadas describen las relaciones con referencias entre documentos, mientras que los modelos denormalizados pueden almacenar información redundante a través de los modelos relacionados.
• Estrategia de indexado
• Representación de datos en arrays en BSON.

Pasemos ya a las consideraciones:

MODELOS DE DATOS EMBEBIDOS:

Para de-normalizar datos se pueden almacenar dos piezas de datos en un único documento.

Las operaciones con un único documento (como en SGBDR) son menos costosas para el servidor que las que envuelven varios documentos

En general se pueden usar modelos de datos embebidos cuando:

• Tienes relaciones de tipo “contains” entre entidades: Model Embedded One-to-One Relationships Between Documents.
• Tienes relaciones one-to-many donde los objetos “many” siempre se ven en el context de los documentos padres:Model Embedded One-to-Many Relationships Between Documents.

Tiene las ventajas de: mejor rendimiento en operaciones de lectura y la habilidad de de recuperar e insertar datos en una única operación de bases de datos.

Como inconvenientes puede llevar a situaciones donde los documentos crecen después de su creación. El crecimiento de los documentos pueden impactar en el rendimiento de escritura y llevar a fragmentar los datos. Hay que tener en cuenta que los documentos deben ser menores que ek tamaño máximo de documento BSON (para documentos mayores usar GridFS).

MODELOS DE DATOS CON REFERENCIAS

Para normalizar datos hay que almacenar referencias entre dos documentos para indicar una relación entre los datos de cada documento.

En general usar modelos de datos normalizados:

• Modelos de datos embebidos llevan a duplicar datos y no dan las suficientes ventajas de rendimiento en la lectura para superar estas implicaciones.
• Representar relaciones complejas many-to-many
• Para modelar data sets jerárquicos grandes: Model Tree Structures in MongoDB.
• · Las referencias dan mayor flexibilidad que los embebidos, aunque implican varias queries desde la capa cliente, y por tanto más idas y vueltas al servidor.

· Ver Model Referenced One-to-Many Relationships Between Documents.

PATRONES DE MODELADO

• Model Embedded One-to-One Relationships Between Documents
• Model Embedded One-to-Many Relationships Between Documents
• Model Referenced One-to-Many Relationships Between Documents
• Model Data for Atomic Operations
• Model Tree Structures with Parent References
• Model Tree Structures with Child References
• Model Tree Structures with Materialized Paths
• Model Tree Structures with Nested Sets

En próximos posts veremos más consideraciones: TTL, índices, sharding,… así como queries con JOINs entre colecciones.