Normalización vs Desnormalización
Hace pocos días me preguntaba como sería si en vez de normalizar las tablas de mis bases de datos me pusiera a desnormalizarlas... suena bastante incoherente para alguien que ha seguido la dogma de diseño de bases de datos tomando en cuenta los conceptos impartidos en la universidad, que principalmente hacen referencia a la primera forma normal, segunda forma normal, tercera forma normal, etc.
Sin entrar a grandes detalles, uno de los resultados casi directos de la normalización tiende a ser la obtención de varias tablas relacionadas unas con otras de una manera física.
Alguien alguna vez me preguntó "¿Es mejor tener varias tablas relacionadas, o sólo una que contenga todos los datos?" . Inmediatamente contesté: No baciles en normalizar tu base de datos, pero eso depende de la aplicación que desarrolles.
Por su puesto que si tu diseño sólo tiene una clase persistente, generalmente deberías tener una tabla representándola, ¿Pero acaso el diseño orientado a objetos tiene una relación 1:1 con el relacional? Claro que no. Así que quien sabe pueden salir varias tablas para representar a tu clase persistente.
Creo que uno de los principales mitos respecto a las consecuencias de normalizar una BBDD es:
- En un motor de BBDD relacional es costoso procesar un join.
Esto generalmente incide en el hecho de que si tienes tres tablas (resultado de una normalización) y luego quieres realizar una consulta sobre las tres tablas, entonces tendrás que hacer 2 joins.
¿Y que tal si sólo tenías una tabla para representar los datos que estaban en esas tres tablas? ¿Sería mas rápido? En las pruebas que he realizado sobre algunas BBDD, he comprobado que el tiempo de respuesta es menor si sólo consultas una sola tabla.
Claro, en una aplicación pequeña esto pasa desapercibido, pero en una aplicación que maneja grandes volúmenes de acceso a datos, de seguro que 1ms cuenta.
Sin embargo, las consultas a una BBDD son solo una pequeña parte de lo que una aplicación hace con ellas. Otro aspecto a considerar es que si quieres eliminar un registro en una tabla, y esa tabla está relacionada con otras, ten por seguro que se tendrá que eliminar tambien de esas tablas. Siguiendo con el ejemplo planteado arriba, para eliminar 1 registro de la tabla principal, tendrás que eliminar 2 registros adicionalmente, resultado: 3 SQLs de eliminación. Algunos dirán que existen los procesos almacenados o los triggers que te permiten configurar y ejecutar procesos dependientes de la BBDD para que elimine automágicamente esos registros dependientes. OK, pero para ello tendrán que decidir si realmente quieren mezclar la lógica de su aplicación con la de su BBDD. Para mi es una mala práctica, ya que hace mas complicado el mantenimiento de una aplicación, ya que no solo tendrán que ver código fuente para entender la lógica, sino también tendrán que ver la BBDD par terminar de entenderla. Según yo, estas uniendo dos capas (layers) que no necesariamente deben ser unidas. Claro que esto depende de tu aplicación, ya que si tu aplicación es centrada en la Base de datos, de seguro que es algo común hacer esto.
Bueno, en fin, creo que hay que equilibrar, creo que hay que saber (y generalmente la experiencia te lo indica) que nieveles de normalización debes aplicar a tu BBDD dependiendo de tu aplicación, y quizá en otros casos tengas que desnormalizar algunas BBDD, evaluando factores como:
- Tamaño de la aplicación.
- Número de accesos concurrentes sobre dichas tablas.
- La lógica de negocio de tu aplicación debería controlar la BBDD y no al revés.
- Velocidad de las consultas.
Comentarios