Autor deambulando | en Programación, Software, Tecnologia | el 05-01-2009
Etiquetas: bbdd, inconvenientes, normalizar, Programación, tablas, tiempo, ventajas
“Normalizar o No Normalizar , esa es la cuestión.” Cuestión de disputa en mi trabajo cuanto menos.
Primero debemos conocer que es Normalizar una BBDD, la wikipedia nos ayuda.
Para los que ya sabéis acerca de la normalización seguramente estáis pensando que estupidez de tema es este! Hay que normalizar SI o SI! yo la verdad soy de estos.
Pero hay que abrir la mente a otros puntos de vista, y la experiencia te hace verlos.
Creo que aún teniendo los conocimientos, siempre es bueno estudiar las opciones que tenemos.
Ventajas Normalización:
- Evitar la redundancia de los datos.
- Evitar problemas de actualización de los datos en las tablas.
- Seguridad de los datos
- Esquema lógico de estructura
- Fácil de entender por otros programadores en un futuro (super importante)
- Escalabilidad
- Tamaño BBDD
Inconvenientes Normalización (cuanto menos cuestionables):
- Muchas mas tablas
- Velocidad de ejecución código (muchos mas join)
- Tiempo diseño de la BBDD
- Tiempo para programar
- Aprendizaje de la normalización.
¿Que es lo mejor que puedo hacer?
Depende cada caso.
Yo recomiendo siempre normalizar una BBDD si o si ;), pero si me comentas es un entorno de hiper estrés que por las querys no hay servidor capaz de soportar eso…te diría normaliza y monta un cluster, si no dispones de presupuesto y tienes tanto tráfico, amigo replanteate el negocio, algo no funciona bien, tantas visitas y no hay negocio? cierra el chiringuito y vamos a la playa.
El caso del tiempo: Importante caballero es don dinero, y el tiempo es dinero es evidente. Sino dispones de tiempo, no es siempre necesario normalizar hast ala 5ª forma, es mas casi todos los proyectos están hasta la 2ª o 3ª, por comodidad, ahorras tablas, y ganas velocidad de programación y de código.
Fuente inspiradora de este post: http://www.realsoftwaredevelopment.com/to-normalize-or-not-to-normalize/
Recomendados:
Cuando usas un Patron basado en Active Record como es mi caso Ruby On Rails, muchas veces la correspondencia entre el modelo y la base de dato es 1 a 1, es decir, Rails usa un modelo MVC (modelo vista controlador) donde el cada clase del model va a ser mapeada a 1 sola correspondiente tabla. Cabe destacar que si llevamos realizamos una normalizacion de la base de datos estariamos forzados a hacer una normalizacion del modelo de objetos… No creo que sea necesario normalizar SIEMPRE.
En mi caso si el framework no me lo exigiera lo mas seguro que si normalizara… pero gracias a dios ActiveRecord hace mucha “magia” y hace mucho mas facil los puntos que vos nombras de:
- Evitar problemas de actualización de los datos en las tablas.
- Seguridad de los datos
- Esquema lógico de estructura
- Fácil de entender por otros programadores en un futuro (si conocen el framework)
Sin necesidad de estar en 3era forma normal :), a todo esto con un sistema de “migraciones” se pueden modificar las tablas de la bd de forma muy sencilla.
Gracias por el aporte ;)
Sobre esos supuestos “problemas” de la normalización…
* Muchas mas tablas
No me parece que eso sea un problema. Cuando diseñas pones las tablas que necesitas, sean muchas o pocas.
* Velocidad de ejecución código (muchos mas join)
Si el diseño es correcto, la ganancia de tiempo por denormalizar y reducir el número de joins va a quedar eclipsada por el aumento del tiempo de desarrollo cuando trates de entender tu propio esquema de tablas.
* Tiempo diseño de la BBDD
Yo también soy de los de normalizar sí o sí, de modo que ganar tiempo a costa de hacer las cosas “mal” no me parece una ventaja.
* Tiempo para programar
Como dice el artículo, tener tablas normalizadas facilita la comprensión del esquema. Teniendo en cuenta que se dedica tanto o más tiempo al mantenimiento de una aplicación como a su desarrollo, el tiempo para programar una bd normalizada es menor, no mayor.
* Aprendizaje de la normalización.
No veo que esto sea un inconveniente. Ya puestos, también podríamos decir que tener que aprender a programar es un inconveniente…
Hola Adri, estoy en casi todo de acuerdo:
* Muchas mas tablas
No me parece que eso sea un problema. Cuando diseñas pones las tablas que necesitas, sean muchas o pocas.
*Ya pero por ejemplo tabla persona, campos direccion1,direccion2
Esta mal normalizada, al normalizarla: tabla personas_direccion, ya tienes 2 tablas en vez de 1
* Velocidad de ejecución código (muchos mas join)
Si el diseño es correcto, la ganancia de tiempo por denormalizar y reducir el número de joins va a quedar eclipsada por el aumento del tiempo de desarrollo cuando trates de entender tu propio esquema de tablas.
Si tienes que hacer un select para sacar el nombre y la direccion consultas a dos tablas, eso es mas lento que consultar a 1, no??
Lo demás esto totalmete de acuerdo ;)
Estoy de acuerdo, hasta la tercera forma normal suele ser más que suficiente.
[...] El otro día mencionaron un post mío en Barrapunto, Normalizar o No Normalizar [...]