Uanset om du arbejder med en database, der indeholder hundredvis af optegnelser eller millioner af optegnelser, er korrekt database design altid vigtigt. Det vil ikke kun gøre det nemmere at hente informationen, det vil også forenkle udvidelsen af databasen i fremtiden. Desværre er det let at falde i et par fælder, der kan gøre tingene vanskelige i fremtiden.
Der er hele bøger skrevet om genstand for normalisering af en database, men hvis du simpelthen undgår de almindelige fejl, der vises her, vil du være på rette spor til god database design.
Database fejl nr. 1: Gentagelse af felter i en tabel
En grundlæggende tommelfingerregel for god database design er at genkende gentagne data og at sætte de gentagne kolonner i deres eget bord. Gentagende felter i en tabel er fælles for dem, der er kommet fra verden af regneark, men mens regneark tendens til at være fladt af design, bør databaser være relationelle. Det er som at gå fra 2D til 3D.
Heldigvis er gentagne felter normalt let at få øje på. Bare tag et kig på denne tabel:
| Ordre ID | Product1 | Product2 | Product3 |
| 1 | Teddybjørne | Jelly beans | |
| 2 | Jelly beans |
Hvad sker der, når en ordre indeholder fire produkter? Vi skal tilføje et andet felt til bordet for at understøtte mere end tre produkter. Og hvis vi har opbygget en klientprogram rundt om bordet for at hjælpe os med at indtaste data, kan det være nødvendigt at ændre det med det nye produktfelt. Og hvordan finder vi alle ordrer med jellybeans i ordren? Vi ville blive tvunget til at forespørge hvert produktfelt i tabellen med en SQL-sætning, der kan se ud: SELECT * FROM PRODUCTS WHERE Product1 = 'Jelly Beans' ELLER Product2 = 'Jelly Beans' ELLER Product3 = 'Jelly Beans'.
I stedet for at have et enkelt bord, der udfylder alle oplysningerne sammen, skal vi have tre tabeller, som hver indeholder et særskilt stykke information. I dette eksempel vil vi have en ordre-tabel med oplysninger om selve ordren, et produkttabell med alle vores produkter og en ProductOrders-tablet, der linkede produkter til ordren.
| Ordre ID | Kunde ID | Bestillingsdato | i alt |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| ProductID | Produkt | Tælle |
| 1 | Teddybjørne | 1 |
| 2 | Jelly beans | 100 |
| ProductOrderID | ProductID | Ordre ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Bemærk hvordan hver tabel har sit eget unikke ID-felt. Dette er den primære nøgle. Vi forbinder tabeller ved at bruge en primær nøgle værdi som en fremmed nøgle i en anden tabel. Læs mere om primærnøgler og fremmednøgler.
Database fejl nr. 2: Embedding af en tabel i en tabel
Dette er en anden almindelig fejl, men det står ikke altid lige så meget som gentagne felter. Når du designer en database, vil du sikre dig, at alle dataene i en tabel vedrører sig selv. Det er som det barns spil om at spotte hvad der er anderledes. Hvis du har en banan, en jordbær, en fersken og et fjernsyn, hører tv-apparatet nok et andet sted.
På samme linje, hvis du har en tabel med salgsmedlemmer, skal alle oplysningerne i den pågældende tabel relateres specifikt til den pågældende sælger. Eventuelle ekstra oplysninger, der ikke er unikke for den pågældende sælger, kan tilhøre et andet sted i din database.
| SalesID | Først | Sidst | Adresse | Telefonnummer | Kontor | OfficeNumber |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Smith | 504 2nd Street, New York, NY | (211) 122-1821 | New York (øst) | (211) 855-4541 |
| 3 | Joe | Sogn | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Mens denne tabel kan se ud som om det hele er relateret til den enkelte sælger, har den faktisk et bord indlejret i bordet. Bemærk hvordan Office og OfficeNumber gentager med "Austin Downtown". Hvad hvis et kontor telefonnummer ændrer sig? Du skal opdatere et helt sæt data for et enkelt stykke information, der ændrer sig, hvilket aldrig er en god ting. Disse felter skal flyttes til deres eget bord.
| SalesID | Først | Sidst | Adresse | Telefonnummer | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Smith | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Sogn | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Kontor | OfficeNumber |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (øst) | (211) 855-4541 |
Denne type design giver dig også mulighed for at tilføje yderligere oplysninger til Office-tabellen uden at skabe et mareridt af rod i salgstabellen. Forestil dig, hvor meget arbejde det ville være at bare holde styr på gadenavn, by, stat og postnummer, hvis alle disse oplysninger var i salgspersonalet bordet!
Database Mistake # 3: Sætte to eller flere stykker information i et enkelt felt
Indlejring af kontoroplysningerne i sælgerbordet var ikke det eneste problem med databasen. Adressefeltet indeholdt tre oplysninger: Gadenavnet, byen og staten. Hvert felt i databasen bør kun indeholde et enkelt stykke information. Når du har flere oplysninger i et enkelt felt, kan det blive sværere at søge databasen for information.
For eksempel, hvad hvis vi ønskede at køre en forespørgsel på alle salgsfolk fra Austin? Vi skal søge inden for adressefeltet, hvilket ikke kun er ineffektivt, men kan returnere dårlige oplysninger. Hvad sker der, hvis nogen boede på Austin Street i Portland, Oregon?
Sådan ser tabellen ud:
| SalesID | Først | Sidst | Adresse 1 | Adresse 2 | by | Stat | Zip | telefon |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Smith | 504 2. St | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Sogn | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Der er et par ting at notere her.For det første synes "Address1" og "Address2" at falde under den gentagne feltfejl.
Men i dette tilfælde henviser de til separate data dele, der direkte vedrører sælgeren i stedet for en gentagende datagruppe, der skal gå i eget bord.
Også, som en bonusfejl for at undgå, bemærke, hvordan formatering for telefonnummeret er blevet fjernet fra bordet. Du bør undgå at gemme formatet af felter, når det er muligt. I tilfælde af telefonnumre er der flere måder, hvorpå folk skriver et telefonnummer: 215-555-5858 eller (215) 555-5858. Dette ville gøre søgning efter en sælger ved deres telefonnummer eller gøre en søgning af salgsfolk i samme områdekode vanskeligere.
Database fejl nr. 4: bruger ikke en korrekt primær nøgle
I de fleste tilfælde vil du bruge et automatisk stigende nummer eller et andet genereret nummer eller alfanumerisk til din primære nøgle. Du bør undgå at bruge nogen egentlig information til primærnøglen, selvom det lyder som om det ville udgøre en god identifikator.
For eksempel har vi hver især vores eget individuelle socialsikringsnummer, så det kan være en god ide at bruge socialsikringsnummeret til en medarbejderdatabase. Men mens det er sjældent, er det muligt for selv et socialt sikkerhedsnummer at ændre sig, og vi vil aldrig have vores primære nøgle til at ændre.
Og det er problemet med at bruge faktiske oplysninger som en nøgleværdi. Det kan ændre sig.
Database fejl nr. 5: Brug ikke en navngivningskonvention
Det kan ikke lyde som en stor ting, når du først kommer i gang med at designe din database, men når du kommer til punktet for at skrive forespørgsler mod databasen for at hente oplysninger, vil det være med en navngivningskonvention, at du husker feltnavne.
Forestil dig, hvor meget sværere den proces ville være, hvis navne blev gemt som FirstName, LastName i en tabel og fornavn, sidste navn i en anden tabel.
De to mest populære navngivningskonventioner kapitaliserer det første bogstav i hvert ord i marken eller adskiller ord ved hjælp af en understregning. Du kan også se nogle udviklere, der aktiverer første bogstav i hvert ord undtagen det første ord: fornavn, sidste navn.
Du vil også gerne beslutte dig for at bruge enslige tabelnavne eller flertalsnavne. Er det et ordre bord eller en ordre bord? Er det en kunde tabel eller kunder bord? Igen vil du ikke sidde fast med et bestillingsbord og et kundes bord.
Den navngivningskonvention du vælger, er ikke lige så vigtig som processen med faktisk at vælge og holde fast i en navngivningskonvention.
Database fejl nr. 6: Forkert indeksering
Indeksering er en af de sværeste ting for at få det rigtige, især for de nye i databasedesign. Alle primærnøgler og fremmednøgler skal indekseres. Disse er, hvad link tabeller sammen, så uden et indeks, vil du se meget dårlig ydeevne ud af din database.
Men hvad der for ofte savnes er de andre felter. Dette er "WHERE" felterne. Hvis du ofte vil indsnævre din søgning ved at bruge et felt i et WHERE-afsnit, vil du tænke på at sætte et indeks på dette felt. Men du ønsker ikke at overdrevent indeksere bordet, hvilket også kan skade præstationen.
Hvordan man beslutter? Dette er en del af billedkunstens design. Der er ingen hårde grænser for, hvor mange indekser du skal lægge på et bord. Primært vil du indeksere et hvilket som helst felt, der ofte bruges i WHERE-klausulen. Læs mere om korrekt indeksering af din database.
