La normalización de bases de datos es una de las vacas sagradas del desarrollo de aplicaciones. Cada curso de programación de pregrado que haya tomado o libro que haya leído probablemente predique la importancia de normalizar las bases de datos.Es hora de desafiar esa verdad. A veces está bien desnormalizar su base de datos!
¿Cuándo debe normalizarse?
La normalización de la base de datos protege la integridad de sus datos. Es una gran idea en muchos casos, y usted debe comenzar cualquier esfuerzo de diseño de base de datos con la normalización en mente. Si puede normalizar su base de datos, ¡hágalo! De hecho,
La conclusión es que usted debería normalizar su base de datos a menos que tenga una buena razón para no hacerlo. La normalización suele ser una buena práctica de diseño. Reduce la información redundante, optimiza el rendimiento y reduce la probabilidad de que se produzcan problemas de integridad de los datos como resultado de tener los mismos datos almacenados en diferentes esquinas de la base de datos.
Algunas buenas razones para no normalizar
Dicho esto, hay algunas buenas razones para no normalizar su base de datos. Veamos algunos:
- Las uniones son caras . La normalización de su base de datos a menudo implica la creación de muchas tablas. De hecho, usted puede terminar fácilmente con lo que usted piensa que debería ser una simple consulta que abarque cinco o diez tablas. Si alguna vez ha intentado hacer una unión de cinco mesas, sabe que funciona en principio, pero en la práctica es muy lenta. Si está construyendo una aplicación web que se basa en consultas de varias uniones contra tablas grandes, puede que se encuentre pensando: “¡Si esta base de datos no estuviera normalizada! Cuando escuchas ese pensamiento en tu cabeza, es un buen momento para considerar la desnormización. Si puede pegar todos los datos utilizados por esa consulta en una sola tabla sin poner realmente en peligro la integridad de sus datos, ¡hágalo! Sea un rebelde y desnormalize su base de datos. ¡No mirarás atrás!
- El diseño normalizado es difícil . Si está trabajando con un esquema de base de datos complejo, probablemente se encontrará golpeando su cabeza contra la mesa por la complejidad de la normalización. Como regla general, si usted está pasando todo el día tratando de averiguar cómo pasar a la cuarta forma normal, es posible que esté llevando la normalización demasiado lejos. Retroceda y pregúntese si realmente vale la pena continuar.
- Rápido y sucio debe ser rápido y sucio . Si sólo estás desarrollando un prototipo, haz lo que sea que funcione rápidamente. De verdad. Está bien. Está bien. El desarrollo rápido de aplicaciones es a veces más importante que el diseño elegante. Sólo recuerde volver atrás y echar un vistazo cuidadoso a su diseño una vez que esté listo para pasar de la fase de creación de prototipos. El precio que usted paga por un diseño de base de datos rápido y sucio es que podría necesitar tirarlo y empezar de nuevo cuando sea el momento de construir para la producción.
- Si está usando una base de datos NoSQL , la normalización tradicional no es deseable. En su lugar, diseñe su base de datos utilizando el modelo BASE, que es mucho más indulgente. Esto es útil cuando se almacenan datos no estructurados como correos electrónicos, imágenes o vídeos.
Algunas palabras de precaución
La normalización de la base de datos es generalmente una buena idea. Usted debe tratar de seguir los principios de normalización cuando le parezca razonable hacerlo. Pero si todos los indicadores indican que la normalización es demasiado compleja de implementar, considere un enfoque que haga el trabajo sin dejar de proteger sus datos.Por último, si decide desviarse de las reglas de normalización, esté muy atento a la forma en que aplica la integridad de la base de datos. Si almacena información redundante, ponga gatillos y otros controles en su lugar para asegurarse de que la información permanezca consistente.
