Normalización no mundo real
A normalización da base de datos é unha das vacas sagradas do desenvolvemento de aplicacións. Cada curso de programación de licenciatura que tomou ou reservou que liches probabelmente predica a importancia de normalizar as bases de datos .
É hora de desafiar ese truismo. Ás veces é correcto desnormalizar a súa base de datos.
Cando se debe normalizar?
A normalización da base de datos protexe a integridade dos teus datos. É unha gran idea en moitos casos, e debería comezar calquera proxecto de deseño de base de datos con normalidade. Se pode normalizar a súa base de datos, vaia por iso. De feito, aquí tes algúns consellos prácticos sobre como normalizar a súa base de datos neste sitio:
- Pór a súa base de datos en primeiro formulario normal (1NF)
- Pór a súa base de datos en segundo formulario normal (2NF)
- Pór a súa base de datos en terceiro formulario normal (2NF)
A conclusión é que debes normalizar a túa base de datos a non ser que teñas unha boa razón para non facelo. A normalización adoita ser unha práctica de deseño acústico. Reduce a información redundante, optimiza o rendemento e reduce a probabilidade de que teña problemas de integridade de datos que resulten de ter os mesmos datos esmagados en diferentes recunchos da túa base de datos.
Algunhas boas razóns para non normalizar
Dito isto, hai algúns bos motivos para non normalizar a súa base de datos. Vexamos uns cantos:
- Unirse son caros . Normalmente, a súa base de datos implica a creación de moitas táboas. De feito, pode superar con facilidade o que pensa que debería ser unha consulta simple que abrangue cinco ou 10 táboas. Se algunha vez intentaches facer unha xuntanza de cinco táboas, xa sabes que funciona en principio, pero é meticulosamente lento na práctica. Se está a construír unha aplicación web que depende de consultas de unificación múltiple en táboas grandes, pode que estea pensando "Se só esta base de datos non estivesen normalizadas". Cando escoite esa idea na súa cabeza, é un bo momento para considere a desnormalización. Se pode manter todos os datos utilizados por esa consulta nunha única táboa sen comprometer a súa integridade de datos, avance. Sexa rebelde e denormaliza a túa base de datos. Non mirarás atrás.
- O deseño normalizado é difícil . Se estás a traballar cun esquema de base de datos complexo, probabelmente che atoparás batendo a cabeza contra a mesa sobre a complejidad da normalización. Como unha simple regra xeral, se estás gastando todo o día tratando de descubrir como avanzar á cuarta forma normal, pode estar tomando a normalización demasiado lonxe. Volva e pregunta se vale a pena continuar.
- Rápido e sucio debe ser rápido e sucio . Se estás só desenvolvendo un prototipo, fagas o que funcione rapidamente. Realmente. Está ben. O desenvolvemento rápido das aplicacións é ás veces máis importante que o deseño elegante. Basta lembrar de volver e coidar co seu deseño unha vez que estea listo para superar a fase de prototipado. O prezo que pagas por un deseño de base de datos rápido e sucio é que podes necesitar tiralo e comezar de novo cando sexa hora de construír para a produción.
- Se está a usar unha base de datos NoSQL , a normalización tradicional non é desexable. No seu canto, debuxa a túa base de datos usando o modelo BASE que é moito máis perdoante. Isto é útil cando está a almacenar datos non estruturados, como correos electrónicos, imaxes ou vídeos.
Algunhas palabras de precaución
Normalmente, a normalización da base de datos é unha boa idea. Debería tratar de seguir os principios de normalización cando pareza razoable facelo. Pero se todos os indicadores sinalan que a normalización é demasiado complexa para implementar, considere un enfoque que fará o traballo mentres segue protexendo os seus datos.
Finalmente, se optas por desviarse das regras de normalización, estea máis atento sobre a forma de facer cumprir a integridade da base de datos. Se almacena información redundante, pon activadores e outros controis no lugar para asegurarse de que a información mantense consistente.