Bones pràctiques en bases de dades relacionals

Mar Llambí

En sóc conscient que molts pensareu: tothom que hagi anat alguna classe o s'hagi llegit algun llibre per aprendre bases de dades hauria de tenir aquesta lliçó superada.... error!

Recordo que el meu professor de bases de dades a la universitat (bé, professors) es ficaven bastant pesats amb temes de convenis, bones pràctiques... són regles i estàndards que ningú havia oficialitzat, però tothom ha de seguir a l'hora de crear models de bases de dades relacionals. Des dels pares desenvolupadors de les bases de dades relacionals com Edgar Frank Codd s’han anat dibuixant les regles entorn d’aquestes.

De bones pràctiques n'hi ha en la programació en si (conceptes que sobretot gent sortida de carrera hauria de tenir ben apresos però... altre cop error). Són indispensables per ajudar a l'entesa del model entre els diferents desenvolupadors que se’l trobin. Si el projecte és únicament teu i n'estàs segur que ningú el continuarà desenvolupant... utilitza igualment aquestes bones pràctiques. T'ajuda a tenir un model net, comprensible i... no saps mai què pot passar en un futur ;)

Perquè és important tenir en compte que aquestes bones pràctiques són per bases de dades relacionals?

Veureu al llarg de l'entrada que moltes tenen a veure amb el nom de les entitats, índexs, relació... i aquests seran específics per aquest tipus de bases de dades. Don't care, intentaré fer-ne una altra entrada al futur per a no relacionals (tot i que aquí, ja entraríem en un món obscur).

Espero aportar una mica de llum, ordre i debat

Modelatge i disseny

  • Establir conveni de nomenament de bases de dades, objectes i obligació a seguir estandardització.
    • Per què? Ajuda a evitar confusió i pèrdua de semàntica dels objectes a crear, per tant ajudarà al manteniment i la interoperabilitat de sistemes més ràpids i efectius.
    • Com?
      • No incloure espais en el nom de les taules, utilitza noms en forma singular per a les taules (la taula representa una col·lecció d’entitats però no és necessari utilitzar noms en plural) i en anglès; si el nom de la taula és compost, només l’última paraula va en plural (exemple ProductSales)
      • No utilitzar prefixos innecessaris (EstudiantTaula, TlaEscola etc només en casos de catàleg, configuració… com conf_xxx, cat_xxx)
      • Anomenar les claus foranes seguint un patró (el més comú és FK_<taula que fa referencia>+<camp que referencia>_<taula_referenciada>+<camp_referenciat>); sempre és millor que siguin numèrics.
      • Els noms dels atributs o columnes han de ser senzills, en singular i depenent dels servidors SQL en un format o altre (Mysql “customerId”, Oracle “CUSTOMER_ID” etc). A gust personal les id sempre les anomeno igual “id” sigui quina sigui la taula.
      • Les claus foranes que referenciïn la mateixa columna, han d’anomenar-se com la columna (en el meu cas s’anomenen NomTaula_columna).
      • No barrejar mai idiomes, jo sempre recomano l’anglès: és net, simple i universal
      • Identificador numèrics per a totes les taules (i si poden ser auto-increment millor).
      • Utilitza format bit per treballar booleans
  • Normalitzar les dades com a mínim fins a la tercera forma normal, sense comprometre el rendiment.
    • Per què? Evita incongruències entre l'esquema de la base de dades i el model de dades, ens ajudarà a aconseguir millor temps de resposta.
    • Com? Assegura’t que els atributs de totes les taules siguin representatius del context de la taula i no estiguin estrictament lligats només a una de les columnes. Per exemple, tens una taula on es referencien usuaris i en la mateixa taula informació única dels usuaris? Vigila les dependències transitives.
  • Obtenció de les consultes més populars a partir de l'anàlisi de requeriments i generació dels primers arbres de consulta previs.
    • Per què? Millorarem el temps de resposta si des de bon inici ja identifiquem el tipus de claus i podem establir els índexs. La generació d'arbres millorarà el temps de resposta si identifiquem quin són els índexs claus en el nostre disseny.
  • Utilitzar tipus de dades si una columna en particular es repeteix en alguna taula
    • Per què? L'estandardització del domini de les dades és essencial per entendre la representació d'una taula, si tenim una columna amb valors que representen variables que pot adquirir un camp, i aquesta columna es repeteix en alguna altra taula, haurem de referenciar-ho a una central. No només cal facilitar l'entesa dels atributs d'una taula, també els valors que aquest pot tenir.
    • Com? Si tenim un camp "rol"  a la taula "usuari" i aquest agafa valors 1,2...5 crear la taula Rol amb "id" l'enter que el representa {1,2,3...} i un camp "nom" on expressi el significat {usuari, admin, gestor..} afegint-lo com a clau forana a la taula "usuari"
  • Definir correctament el tipus de dades que poden representar els nostres atributs
    • Per què? Altre cop per estandarditzar la taula, per facilitar l'obtenció de les dades fora de la base de dades i crear-ne un domini correcte.
    • Com? Juga amb els Varchars i les seves longituds, no defineixis atributs com enters de molts bytes si saps que només arribaran fins a cert valor..
  • Evitar utilitzar SQL dinàmic si no és imprescindible
    • Per què? Existeix la possibilitat que l’usuari injecti codi i elimini i corrompi part de la informació. A més, com és dinàmic, cada vegada necessita compilar-se i generar el pla d’execució. D’aquesta manera obtindrem sistemes més segurs i estables.
  • Documenta qualsevol disseny que realitzis
    • Per què? És una mala idea dissenyar una base de dades i no documentar-la, amb el temps no recordaràs perquè vas perdre segons quines decisions o per traspassar el disseny t’hi estaràs una bona estona. Imagina’t finalment, que algú aliè ha d’acabar treballant amb ella…
    • Com? Genera diagrames ER, fes comentaris sobre possibles decisions crítiques, documenta els triggers, afegeix comentaris a atributs difícils d’entendre… jo et recomano treballar amb un MySQL Workbench o semblants.

Accés a les dades

  • Evitar utilitzar consultes SQL amb camps no necessaris
    • Per què? Quan elaborem consultes de l’estil “SELECT *” segurament estem agafant columnes que no ens interessin, i per tant el temps de resposta és més alt i el sistema augmenta l’accés al disc.
    • Com? Especificar els camps que necessitem a la consulta
  • Evita utilitzar comodins a l’inici de la paraula LIKE “%omes”
    • Per què? És la teoria de l’índex scan vs índex search, el mode que s’executa la cerca és diferent i per descomptat, el temps de resposta també. La cerca seqüencial que fa por provocar problemes de concurrència.
    • Com? Substituint sempre que poguem per comodins entre paraula LIKE “p%es”
  • Evita utilitzar operadors de negació (<> i not) si no és necessari
    • Per què? El sistema com que no te un valor en concret realitza una cerca en tot l’arbre, provocant cerques lentes i problemes de concurrència.

Treballar amb les dades

  • Intenta utilitzar columnes “active” en comptes de esborrar les files
    • Per què? N’estàs segur que pots esborrar aquella entrada? I si en depèn una altra? i si la tornes a necessitar. Fes un doble sistema de seguretat per evitar inconsistència a la base de dades
    • Com? Incorporant una columa active que tingui els valors booleans 1 o 0 i que un procés després de cert temps, esborri tots aquells que estan a 0.
  • Utilitzar constraints per revisar la integritat referencial
    • Per què? L’ús de constraints és una manera de reduir el domini de les dades. La programació per triggers ve precedit per un entorn de processos i per tant més lent.
    • Com? Revisar la integritat referencial a través dels constraints, si són massa complicats llavors utilitzar triggers.
  • Centralització de feines al front/backend del teu software
    • Per què? El gestor s’allibera de treballs senzills i pot atendre més processos que requereixen una gestió de la informació resident de la base de dades. Per tant tindrem una alliberació de la carga innecessària.
    • Com? Realitzar manipulacions de cadenes, concatenacions, nomenament de registres, conversions… al nostre software.
  • No fer la mateixa crida diversesvegades en un mateix programa.
    • Per què? Perquè volem una utilització òptima de la memòria i el processat i així millorar el temps de resposta. Evitem així usos innecessaris de memòria i baixa concurrència.
    • Com? Si una crida la necessites dues vegades en una funció, guarda el resultat en una variable. Si no és canviant i el necessitaràs molt, fes la variable global o atribut.
  • Mantenir les contrasenyes encriptades a la base de dades.
    • Per què? Un password és la clau d’entrada d’un usuari a totes les seves dades i accions. No només protegeixes el compte en cas d’accés d’aliens a la base de dades, sinó que dibuixes un tel entre l’enginyer que dóna suport a la base de dades i la privacitat/seguretat de l’usuari.
    • Com? Desencripta’ls a l’aplicació, preferiblement backend, inaccessible a nivell d’usuari.
  • Mantenir sempre un sistema de backups i recuperació
    • Per què? Qualsevol error provocaria un desastre si no som capaços de garantir l’estabilitat i integritat de les dades.
    • Com? Configurar backups automàtics i logs per saber en quin moment hem de restaurar alguna versió. Recomano personalment treballar amb clusters per garantir l’estabilitat in time.



He intentat doncs agrupar algunes de les més essencials, podríem entrar en temes de seguretat (usuaris, rols i contrasenyes) o en correcte disseny d’Entitats-Relació, però d’alguna manera he volgut resumir aquells temes que va més enllà de com extraiem les classes o relacions d’un projecte.
Espero que us serveixi i espero escoltar la vostra experiència i opinió!

Que tingueu molt bon dia i bases de dades estables!

0 Comentarios