Desnormalización

Desnormalizacion

Es el proceso de optimizar el funcionamiento de una BD agregando datos redundantes.

• Esto es hacer duplicidad de datos y agregar direcciones no essenciales para acelerar las consultas o reducir la cantidad.

• Esta mal visto la duplicidad de datos en una base de datos relacional, pero en una base de datos documental puede ser un aliado. Porque nos ahorramos consultas o aceleramos esas mismas consultas por tener indexacion.

• Tambien permite mantener datos historicos, datos que no queremos que cambien en una instancia, aunque tengan cambios sus origines.

• Reduce los Join y simplifica las consultas.

Ejemplo

Tenemos una coleccion ‘order’ que esta desnormalizada, donde se hace embeding a los productos como items. Estos tendran la referencia sus productos correspondientes (product_id), datos extra como la cantidad (qty) y datos que pueden o no ser actualizados por ser una instancia de la orden (title, price) y que se quieran acceder rapidamente.

Insercion

db.orders.insertOne({
    user_id: ObjectId('6497b8b4affb4e4355c4f297'),
    date: '2020-12-12',
    items: [
        {
            name: 'Producto 1',
            qty: 1,
            price: 12,
            product_id: ObjectId('649923f457514437ac501dd4')
        },
        {
            name: 'Producto 2',
            qty: 2,
            price: 22,
            product_id: ObjectId('649923f457514437ac501dd4')
        }
    ]
})

Seria muy interesante ahondar mas en el tema de los patrones de MongoDB, ya que parece ser un tema central en el modelado de las DB NoSQL.

Nunca se me había ocurrido este método.
Básicamente combinar un objeto embebido, con una relación referenciada y repetir los campos importantes (también presentes en la relación anterior) para poder acceder a ellos rápidamente, y si hace falta algo mas especifico, llamar a la relación como tal para tener la información completa, es brillante.

La desnormalización la encontré en la práctica, me era mas sencillo guardar ciertos datos en un mismo documento para realizar un reporte mas adelante. Se complica si tienes relaciones pero si haces desnormalización se simplifica muchísimo. Excelente ejemplo de esta clase.

Desnormalización
La desnormalización en MongoDB es un proceso mediante el cual se optimiza la consulta de datos al duplicar y almacenar datos redundantes en una colección o documento. Este enfoque se utiliza para mejorar el rendimiento de consultas a expensas de la consistencia y eficiencia en el almacenamiento.

Cuando normalizamos datos, los dividimos en múltiples colecciones o documentos relacionados para minimizar la redundancia y mejorar la consistencia. Sin embargo, esta estructura normalizada puede requerir unión de datos de múltiples colecciones para realizar consultas complejas, lo cual puede afectar el rendimiento.

¿Cuándo usar la desnormalización?

La desnormalización en MongoDB puede ser beneficiosa en ciertos escenarios, especialmente cuando se trata de optimizar el rendimiento de consultas frecuentes. Sin embargo, como mencionaste, también puede llevar a problemas de consistencia de datos. Aquí te muestro algunos escenarios en los que se debería y no se debería utilizar la desnormalización, junto con las razones:

Cuándo se debería usar la desnormalización:

Escenarios de solo lectura o lectura predominantemente: Si tus consultas son principalmente de lectura y rara vez se actualizan los datos, la desnormalización puede ser apropiada. Esto se debe a que la desnormalización optimiza las consultas de lectura, pero puede generar complicaciones al actualizar los datos.

Consultas frecuentes que implican múltiples colecciones: Si tienes consultas que requieren unir datos de múltiples colecciones y estas consultas son frecuentes, desnormalizar los datos puede mejorar significativamente el rendimiento al evitar operaciones de unión complejas.

Tamaño limitado de datos y baja volatilidad: Si los conjuntos de datos son relativamente pequeños y la volatilidad de los datos es baja, la desnormalización puede ser menos problemática. En estos casos, la redundancia de datos no supondría un gran problema y los beneficios en el rendimiento serían más evidentes.

Cuándo no se debería usar la desnormalización:

• Escenarios de alta volatilidad de datos: Si los datos se actualizan o modifican con frecuencia, la desnormalización puede llevar a inconsistencias y errores si no se actualizan correctamente todos los documentos redundantes. La normalización es más segura en estos casos, ya que evita la redundancia de datos y garantiza la consistencia.
• Escenarios de transacciones complejas: Si tus operaciones requieren transacciones complejas que afectan a múltiples documentos relacionados, la desnormalización puede complicar la gestión de estas transacciones y aumentar el riesgo de inconsistencia de datos.
• Escalabilidad y necesidades futuras: Si anticipas un crecimiento significativo en el tamaño y la complejidad de tus datos en el futuro, la desnormalización puede dificultar la escalabilidad y el mantenimiento a largo plazo. La normalización proporciona una estructura más flexible que puede adaptarse mejor a futuras necesidades.