Ja sigui que estigui treballant amb una base de dades que contingui centenars de registres o milions de registres, el disseny adequat de la base de dades sempre és important. No només facilitarà la recuperació de la informació, sinó que també simplificarà ampliar la base de dades en el futur. Desafortunadament, és fàcil caure en unes poques coses que poden fer que les coses siguin difícils en el futur.
Hi ha llibres sencers escrits sobre el tema de normalitzar una base de dades, però si simplement eviteu els errors comuns que es mostren aquí, estaràs en el bon camí per a un bon disseny de base de dades.
Error de base de dades n. ° 1: repetició de camps en una taula
Una regla bàsica per al bon disseny de bases de dades és reconèixer la repetició de dades i posar aquestes columnes repetides a la seva pròpia taula. La repetició de camps en una taula és comú per a aquells que provenen del món dels fulls de càlcul, però mentre que els fulls de càlcul solen ser plans per disseny, les bases de dades han de ser relacionals. És com passar de 2D a 3D.
Afortunadament, els camps repetitius solen ser fàcils de detectar. Fes una ullada a aquesta taula:
| Ordre ID | Producte1 | Producte 2 | Producte3 |
| 1 | Óssos de peluix | Gometes | |
| 2 | Gometes |
Què passa quan un ordre conté quatre productes? Caldria afegir un altre camp a la taula per donar suport a més de tres productes. I si hem creat una aplicació client al voltant de la taula per ajudar-nos a introduir dades, és possible que hàgim de modificar-lo amb el nou camp de producte. I com podem trobar totes les comandes amb Jellybeans en l'ordre? Ens veiem obligats a consultar cada camp de producte a la taula amb una instrucció SQL que podria semblar: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' O Product2 = 'Jelly Beans' O Product3 = 'Jelly Beans'.
En lloc de disposar d'una taula que contingui tota la informació, hauríem de tenir tres taules que cadascun tingui una informació diferent. En aquest exemple, volem una taula d'ordres amb informació sobre el propi ordre, una taula de productes amb tots els nostres productes i una tableta de productes que uneix productes amb l'ordre.
| Ordre ID | Identificació de client | Data d'Ordre | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| ProductID | Producte | Compte |
| 1 | Óssos de peluix | 1 |
| 2 | Gometes | 100 |
| ProductOrderID | ProductID | Ordre ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Observeu com cada taula té el seu propi camp d'identificació únic. Aquesta és la clau principal. Veiem taules utilitzant un valor de clau principal com una clau externa en una altra taula. Llegiu més sobre claus primàries i claus estrangeres.
Error de base de dades n. ° 2: incrustar una taula en una taula
Aquest és un altre error comú, però no sempre es destaca tant com els camps repetitius. Quan es dissenyi una base de dades, es vol assegurar-se que totes les dades d'una taula es relacionen amb ell mateix. És com el joc d'aquest nen a l'hora de veure el que és diferent. Si teniu plàtans, una maduixa, un presseguer i un televisor, el televisor probablement pertany a un altre lloc.
En la mateixa línia, si teniu una taula de venedors, tota la informació d'aquesta taula hauria de relacionar-se específicament amb aquest venedor. Qualsevol informació addicional que no sigui exclusiva d'aquesta persona de vendes pot pertànyer a un altre lloc de la vostra base de dades.
| SalesID | Primer | Últim | adreça | Número de telèfon | Oficina | OfficeNumber |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Smith | 504 2nd Street, Nova York, Nova York | (211) 122-1821 | Nova York (est) | (211) 855-4541 |
| 3 | Joe | Parròquia | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Si bé aquesta taula pot semblar que està relacionada amb el venedor individual, en realitat té una taula incrustada a la taula. Observeu com repeteixen Office and OfficeNumber amb "Austin Downtown". Què passa si un número de telèfon de l'oficina canvia? Hauríeu d'actualitzar tot un conjunt de dades per canviar un sol fragment d'informació, cosa que mai no és bona. Aquests camps s'han de traslladar a la seva pròpia taula.
| SalesID | Primer | Últim | adreça | Número de telèfon | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Smith | 504 2nd Street, Nova York, Nova York | (211) 122-1821 | 2 |
| 3 | Joe | Parròquia | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Oficina | OfficeNumber |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | Nova York (est) | (211) 855-4541 |
Aquest tipus de disseny també us permet afegir informació addicional a la taula d'Office sense crear un malson de desordre a la taula de vendes. Imagineu-vos el treball que seria simplement fer un seguiment de l'adreça postal, ciutat, estat i codi postal si tota aquesta informació es trobava a la taula de vendes.
Error de base de dades n. ° 3: posar dues o més peces d'informació en un únic camp
La integració de la informació de l'oficina a la taula de vendes no era l'únic problema amb aquesta base de dades. El camp d'adreces conté tres informacions: l'adreça postal, la ciutat i l'estat. Cada camp de la base de dades només ha de contenir una sola informació. Quan tingueu diversos elements d'informació en un sol camp, pot ser més difícil de consultar la base de dades per obtenir informació.
Per exemple, què passaria si volíem fer una consulta a tots els venedors d'Austin? Hauríem de cercar dins del camp d'adreça, que no només és ineficient, sinó que pot retornar informació incorrecta. Després de tot, què passa si algú vivia al carrer Austin de Portland, Oregon?
A continuació us indiquem com hauria de ser la taula:
| SalesID | Primer | Últim | Adreça 1 | Adreça 2 | ciutat | Estat | Zip | Telèfon |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Smith | 504 2n St | Nova York | NY | 10022 | 2111221821 | |
| 3 | Joe | Parròquia | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Hi ha algunes coses que cal tenir en compte aquí.En primer lloc, "Address1" i "Address2" semblen caure sota l'error dels camps repetitius.
Tanmateix, en aquest cas es refereixen a dades separades que es relacionen directament amb la persona de vendes en comptes d'un grup de dades repetit que ha d'anar a la seva pròpia taula.
A més, com un error addicional per evitar, observeu com s'ha eliminat el format del número de telèfon de la taula. Heu d'evitar emmagatzemar el format dels camps quan sigui possible. En el cas dels números de telèfon, hi ha moltes maneres en què les persones escriuen un número de telèfon: 215-555-5858 o (215) 555-5858. Això farà que la cerca d'una persona de vendes pel seu número de telèfon o la cerca de persones de vendes en el mateix codi d'àrea sigui més difícil.
Error de base de dades n. ° 4: No s'utilitza una clau primària correcta
En la majoria de casos, voldreu utilitzar un número d'increment automàtic o algun altre nombre generat o alfanumèric per a la vostra clau principal. Hauríeu d'evitar utilitzar qualsevol informació real de la clau principal, fins i tot si semblava que seria un bon identificador.
Per exemple, cada un té el nostre propi número de seguretat social individual, de manera que utilitzar el número de seguretat social per a una base de dades dels empleats pot semblar una bona idea. Però tot i que és estrany, és possible que canviïn fins i tot un número de seguretat social i mai no volem canviar la nostra clau principal.
I aquest és el problema amb l'ús de la informació real com a valor clau. Pot canviar.
Error de base de dades n. ° 5: No s'utilitza una convenció de nomenclatura
Això pot ser que no sembli molt quan comenci a dissenyar la vostra base de dades, però una vegada que arribeu al punt d'escriure consultes contra la base de dades per recuperar informació, tenir una convenció de noms us ajudarà a memoritzar noms de camp.
Imagineu quant més difícil seria aquest procés si els noms s'emmagatzemen com FirstName, LastName en una taula i first_name, last_name en una altra taula.
Les dues convencions de nomenclatura més populars són la majúscula de la primera lletra de cada paraula del camp o la separació de paraules amb un guió baix. També podeu veure alguns desenvolupadors capitalitzant la primera lletra de cada paraula excepte la primera paraula: firstName, lastName.
També voldreu decidir sobre l'ús de noms de taula singulars o noms de taules en plural. És una taula d'ordre o una taula d'ordres? És una taula de clients o una taula de clients? De nou, no voleu quedar encallat amb una taula de comanda i una taula de clients.
La convenció de noms que trieu no és tan important com el procés de selecció i adhesió a una convenció de nomenclatura.
Error de base de dades n. ° 6: indexació impròpia
La indexació és una de les coses més difícils d'aconseguir, especialment per als nous en el disseny de bases de dades. Totes les claus primàries i claus estrangeres s'han d'indexar. Aquestes són les taules de vincles, de manera que, sense un índex, veureu un rendiment molt baix de la vostra base de dades.
Però el que sovint es perden són els altres camps. Aquests són els camps "ON". Si sovint es va a restringir la cerca mitjançant un camp en una clàusula WHERE, es vol pensar en posar un índex en aquest camp. No obstant això, no voleu indexar massa la taula, que també pot fer malbé el rendiment.
Com decidir? Això forma part de l'art del disseny de bases de dades. No hi ha límits difícils en quants índexs hauríeu de posar en una taula. Principalment, voleu indexar qualsevol camp que s'utilitzi sovint en una clàusula WHERE. Llegiu més sobre indexar correctament la vostra base de dades.
