¿Qué es la desnormalización en bases de datos documentales?
La desnormalización es un concepto clave en la optimización de bases de datos documentales, especialmente si vienes de un entorno de bases de datos relacionales como Postgres o MySQL. A diferencia de la normalización de datos, que busca evitar la redundancia, la desnormalización agrega datos redundantes para mejorar el rendimiento. Este proceso, aunque va contra las prácticas tradicionales de evitar la duplicidad en bases de datos relacionales, es un aliado en contextos donde las consultas rápidas y eficientes son necesarias.
¿Cómo aplicar la desnormalización en un e-commerce?
En el ejemplo de un e-commerce que maneja órdenes de compra, ya se tiene un sub-arreglo de ítems con todos los productos. En lugar de solo referenciar los productos por su ID, podemos desnormalizar nuestra base de datos repitiendo valores clave directamente en las órdenes de compra.
Vector de ítems: Se crea un array llamado items donde se incluye la cantidad de producto, el título y el precio. Aunque estos datos ya existen en la colección de productos, su duplicación evita la necesidad de consultas adicionales para obtenerlos.
Referencia adicional: Aunque hay datos redundantes, se mantiene una referencia hacia el producto original para obtener más información si es necesario.
Esta estrategia permite optimizar procesos como la generación de facturas, ya que la información requerida está fácilmente accesible sin realizar múltiples consultas.
Ventajas de la desnormalización
Optimización de consultas: Al tener datos redundantes, se reducen las consultas necesitando menos operaciones para obtener información sobre productos específicos.
Información histórica: Guarda el precio y detalle del producto al momento de la compra, lo que es útil si posteriormente los precios cambian por inflación u otros factores.
Implementación práctica en código
Altamente útil en el contexto de un servidor o web service:
// Ejemplo de implementación de desnormalización en una orden de compraconst order ={items:[{productId:"12345",title:"Product 1",price:12,quantity:2},{productId:"67890",title:"Product 2",price:45,quantity:1}],userId:"user123"};
En este código, se incluye la información esencial del producto en la orden, evitando consultas para generar una factura completa o visualizar el historial de compras.
¿Cómo afectará la desnormalización a la estructura de tu base de datos?
Al implementar la desnormalización, tu rol se centra en administrar coherentemente el modelo de datos. No se trata solo de insertar valores a mano, sino de automatizar el proceso a través de aplicaciones o servicios web que procesen y almacenen datos eficientemente con las reglas de negocio adecuadas.
Puedes verificar y visualizar documentos en tu base de datos usando técnicas como find en entornos de MongoDB:
db.orders.find({_id:"orderId"});
Esta consulta muestra cómo quedó estructurada la orden, permitiéndote verificar que la desnormalización se ha implementado correctamente. Además, aumenta la eficiencia al evitar un aggregate para buscar información que ya está disponible.
Con este enfoque, se logra un equilibrio entre la eficiencia de consultas y la integridad de datos, lo cual es crucial para el éxito en la gestión de datos en un entorno de bases de datos documentales. Aprovecha lo aprendido para seguir explorando patrones avanzados como el "computed pattern" que también mejorará la funcionalidad de tus aplicaciones. ¡La práctica constante perfeccionará tu dominio en la administración de bases de datos documentales!
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.
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.
yo le agregaría que te ahorras un problema enorme de andar creando tablas transaccionales por concepto o contexto. Es más, ahora me hace más sentido usar esto para una aplicación de pagos, para después diseñar las tablas de análisis según la necesidad. Te das cuenta de que se presta bellísimo para la construcción de cosas OLTP y OLAP sin complicaciones al inicio!!
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.
Buen aporte.
Para complementar:
Hace poco en SQL hice un proceso de desnormalización para guardar la información de entidades relacionadas y no tener que hacerle joins a cada rato. Esto lo hice para una tabla de factura. Creo que los casos de uso más frecuentes de desnormalización son para hacer algo así... facturas, reportes, etc.
Me costó entender algo que ya había aplicado XD
Justo he procedido relacionando con el id y con la data