He de normalitzar la meva base de dades?

Normalització al món real

La normalització de la base de dades és una de les vaques sagrades del desenvolupament d'aplicacions. Cada curs de programació de grau que heu pres o llibre que hàgiu llegit predica la importància de normalitzar les bases de dades .

Ha arribat el moment de desafiar aquesta veritat. De vegades està bé desnormalitzar la vostra base de dades.

Quan hauria de normalitzar?

La normalització de la base de dades protegeix la integritat de la vostra informació. És una bona idea en molts casos, i hauria de començar qualsevol esforç de disseny de base de dades amb la normalització. Si podeu normalitzar la vostra base de dades, aneu-hi! De fet, hi ha alguns consells pràctics sobre com normalitzar la seva base de dades en aquest lloc:

La conclusió és que heu de normalitzar la vostra base de dades tret que tingui una bona raó per no fer-ho. La normalització sol ser una bona pràctica de disseny. Redueix la informació redundant, optimitza el rendiment i redueix la probabilitat que tingui problemes d'integritat de dades que resultin d'haver tingut les mateixes dades en diferents racons de la vostra base de dades.

Algunes bones raons per no normalitzar

Dit això, hi ha algunes bones raons per no normalitzar la vostra base de dades. Vegem alguns:

  1. Les unions són cares . Normalitzar la vostra base de dades sovint implica crear moltes taules. De fet, podeu acabar fàcilment amb la vostra opinió que hauria de ser una consulta senzilla que abasti cinc o deu taules. Si alguna vegada heu intentat fer una unió de cinc taules, ja sabeu que funciona en principi, però és acuradament lent en la pràctica. Si esteu construint una aplicació web que confia en consultes d'unió múltiple contra taules grans, podeu trobar-vos pensant: "Si tan sols aquesta base de dades no estigui normalitzada". Quan escolteu aquest pensament al vostre cap, és un bon moment considereu la desnaturalització. Si podeu enganxar totes les dades que utilitza aquesta consulta en una sola taula sense posar en perill la vostra integritat de dades, feu-ne una. Ser rebel i desnormalizar la vostra base de dades. No miraràs cap enrere.
  2. El disseny normalitzat és difícil . Si esteu treballant amb un esquema de base de dades complex, probablement us trobeu colpejant el vostre cap contra la taula sobre la complexitat de la normalització. Com a simple regla general, si esteu gastant tot el dia intentant esbrinar com passar a la quarta forma normal, podeu fer que la normalització sigui massa lluny. Torna enrere i pregunteu si val la pena continuar.
  1. Ràpid i brut ha de ser ràpid i brut . Si només esteu desenvolupant un prototip, feu tot el que funcioni amb rapidesa. En realitat. Està bé. El desenvolupament d'aplicacions ràpid és de vegades més important que el disseny elegant. Simplement, recordeu tornar enrere i fer una ullada acurada al disseny una vegada que estigui preparat per passar més enllà de la fase de prototipatge. El preu que pagueu per un disseny de base de dades ràpid i brut és que és possible que hàgiu de tirar-lo i començar de nou quan és el moment de construir-se per a la producció.
  2. Si utilitzeu una base de dades NoSQL , la normalització tradicional no és desitjable. En comptes d'això, dissenyeu la vostra base de dades amb el model BASE , que és molt més indulgent. Això és útil quan s'estalvien dades no estructurals, com ara correus electrònics, imatges o vídeos.

Algunes paraules de precaució

Normalment, la normalització de la base de dades és una bona idea. Heu d'intentar seguir els principis de normalització quan sembla raonable fer-ho. Però si tots els indicadors indiquen que la normalització és massa complicada d'implementar, consideri un enfocament que faci el treball mentre protegeixi les dades.

Finalment: si decideixes apartar-vos de les normes de normalització, tingueu més vigilància sobre la manera d'imposar la integritat de la base de dades. Si emmagatzema informació redundant, poseu activadors i altres controls en el lloc per assegurar-vos que la informació es manté constant.