Enten du jobber med en database som inneholder hundrevis av poster eller millioner av poster, er riktig database design alltid viktig. Ikke bare vil det gjøre det enklere å hente informasjonen, det vil også forenkle utvidelsen av databasen i fremtiden. Dessverre er det lett å falle inn i noen få feller som kan gjøre ting vanskelig i fremtiden.
Det er hele bøker skrevet om gjenstand for normalisering av en database, men hvis du bare unngår de vanlige feilene som vises her, vil du være på rett spor til god database design.
Database feil # 1: Gjentatte felt i et bord
En grunnleggende tommelfingerregel for god databaseutforming er å gjenkjenne gjentatte data og å sette de gjentatte kolonnene i sitt eget bord. Gjentatte felt i et bord er vanlige for de som kommer fra verden av regneark, men når regneark pleier å være flatt av design, bør databaser være relasjonelle. Det er som å gå fra 2D til 3D.
Heldigvis er gjentatte felt vanligvis lett å få øye på. Bare ta en titt på dette bordet:
| Bestillings ID | Produkt1 | PRODUCT2 | Product3 |
| 1 | Teddy Bears | Gelé bønner | |
| 2 | Gelé bønner |
Hva skjer når en bestilling inneholder fire produkter? Vi må legge til et annet felt i tabellen for å støtte mer enn tre produkter. Og hvis vi har bygget en klientprogram rundt bordet for å hjelpe oss med å skrive inn data, må vi kanskje endre det med det nye produktfeltet. Og hvordan finner vi alle ordrene med Jellybeans i bestillingen? Vi ville bli tvunget til å spørre hvert produktfelt i tabellen med en SQL-setning som kan se ut: SELECT * FROM PRODUCTS WHERE Product1 = 'Jelly Beans' ELLER Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.
I stedet for å ha et enkelt bord som fyller all informasjon sammen, bør vi ha tre tabeller som hver har et tydelig stykke informasjon. I dette eksemplet vil vi ha en ordre-tabell med informasjon om selve bestillingen, et produkttabell med alle våre produkter og en ProductOrders-nettbrett som koblet produkter til bestillingen.
| Bestillings ID | Kunde ID | Bestillingsdato | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Produkt ID | Produkt | Telle |
| 1 | Teddy Bears | 1 |
| 2 | Gelé bønner | 100 |
| ProductOrderID | Produkt ID | Bestillings ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Legg merke til hvordan hver tabell har sitt eget unike ID-felt. Dette er den primære nøkkelen. Vi kobler tabeller ved å bruke en primærnøkkelverdi som en fremmednøkkel i en annen tabell. Les mer om primærnøkler og utenlandske nøkler.
Database feil # 2: Embedding et bord i et bord
Dette er en annen vanlig feil, men det står ikke alltid like mye som gjentatte felt. Når du designer en database, vil du sørge for at alle dataene i et bord er knyttet til seg selv. Det er som barnets spill om å spotte hva som er annerledes. Hvis du har en banan, en jordbær, en fersken og et TV-apparat, tilhører TV-apparatet trolig et annet sted.
På samme linje, hvis du har et bord med selgere, bør all informasjonen i den tabellen relateres spesifikt til den aktuelle selgeren. Eventuell ekstra informasjon som ikke er unik for den selgeren, kan tilhøre et annet sted i databasen din.
| SalesID | Først | Siste | 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 | Menighet | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Mens dette bordet kan se ut som det er alt knyttet til den enkelte selger, har den faktisk et bord innebygd i bordet. Legg merke til hvordan Office og OfficeNumber gjentar med "Austin Downtown". Hva om et telefonnummer til kontoret endres? Du må oppdatere et stort sett med data for et enkelt stykke informasjon, noe som aldri er bra. Disse feltene skal flyttes til eget bord.
| SalesID | Først | Siste | 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 | Menighet | 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 typen design gir deg også muligheten til å legge til tilleggsinformasjon til Office-bordet uten å skape et mareritt av rot i salgstabellen. Tenk deg hvor mye arbeid det ville være å bare holde oversikt over gateadressen, byen, staten og postnummeret hvis all den informasjonen var i salget bordet!
Database Mistake # 3: Å sette to eller flere stykker informasjon inn i et enkelt felt
Embedding av kontorinformasjonen i selgerbordet var ikke det eneste problemet med databasen. Adressefeltet inneholdt tre opplysninger: gateadressen, byen og staten. Hvert felt i databasen skal bare inneholde ett enkelt stykke informasjon. Når du har flere opplysninger i et enkelt felt, kan det bli vanskeligere å spørre databasen for informasjon.
For eksempel, hva om vi ønsket å kjøre en spørring på alle salgsmedlemmer fra Austin? Vi må søke i adressefeltet, som ikke bare er ineffektivt, men kan returnere dårlig informasjon. Tross alt, hva skjer hvis noen bodde på Austin Street i Portland, Oregon?
Slik ser tabellen ut:
| SalesID | Først | Siste | Adresse 1 | Adresse 2 | By | Stat | Glidelås | telefon |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Smith | 504 andre st | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Menighet | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Det er et par ting å merke seg her.Først vil "Address1" og "Address2" synes å falle under gjentakende feltfeil.
Men i dette tilfellet refererer de til adskilte datamaterialer som er direkte relatert til selgeren i stedet for en gjentatt gruppe data som skal gå i sitt eget bord.
Også, som en bonusfeil for å unngå, legg merke til hvordan formateringen for telefonnummeret har blitt fjernet ut av bordet. Du bør unngå å lagre formatet på felt når det er mulig. I tilfelle av telefonnumre er det flere måter folk skriver et telefonnummer på: 215-555-5858 eller (215) 555-5858. Dette ville gjøre å søke etter en selger ved deres telefonnummer eller gjøre et søk av selgere i samme retningsnummer vanskeligere.
Database feil # 4: Ikke bruk en korrekt primærnøkkel
I de fleste tilfeller vil du bruke et automatisk økende nummer eller et annet generert nummer eller alfanumerisk for primærnøkkelen din. Du bør unngå å bruke noen faktiske opplysninger for primærnøkkelen, selv om det høres ut som om det ville gi en god identifikator.
For eksempel har vi hver sitt eget individuelle personnummer, så det kan hende at bruk av personnummeret for en ansatt database kan høres ut som en god ide. Men mens det er sjeldent, er det mulig for selv et personnummer å forandre, og vi vil aldri ha vår primære nøkkel for å forandre seg.
Og det er problemet med å bruke faktisk informasjon som en nøkkelverdi. Det kan endres.
Database feil nr. 5: Bruker ikke en navnekonvensjon
Dette kan ikke høres ut som en stor avtale når du først begynner å designe databasen din, men når du kommer til å skrive spørringer mot databasen for å hente informasjon, vil det ha en navngivningskonvensjon som du vil huske feltnavn.
Tenk deg hvor mye vanskeligere prosessen ville være hvis navnene ble lagret som Fornavn, LastName i ett bord og fornavn, siste navn i et annet bord.
De to mest populære navngivningskonvensjonene er å kapitalisere det første bokstaven i hvert ord i feltet eller å skille ord ved hjelp av et understrek. Du kan også se noen utviklere som kapitaliserer første bokstav i hvert ord, bortsett fra det første ordet: fornavn, etternavn.
Du vil også ønske å bestemme deg for å bruke enslige tabellnavn eller flertallsnavn. Er det et bestillingsbord eller et bestillingsbord? Er det et Kundebord eller Kundebord? Igjen, du vil ikke bli sittende fast med et bestillingsbord og et kundes bord.
Navngivningskonvensjonen du velger er ikke like viktig som prosessen med å faktisk velge og stikke til en navngivningskonvensjon.
Database feil # 6: Feil indeksering
Indeksering er en av de vanskeligste tingene for å få riktig, spesielt for de nye på databasedesign. Alle primærnøkler og utenlandske nøkler bør indekseres. Disse er hvilke koblingstabeller sammen, så uten en indeks, vil du se svært dårlig ytelse ut av databasen.
Men det som er for ofte savnet er de andre feltene. Dette er "WHERE" -feltene. Hvis du ofte skal begrense søket ditt ved å bruke et felt i en WHERE-setning, vil du tenke på å sette en indeks på feltet. Du ønsker imidlertid ikke å overdrive tabellen, noe som også kan skade ytelsen.
Hvordan bestemme seg? Dette er en del av kunsten til databasedesign. Det er ingen harde grenser på hvor mange indekser du bør legge på et bord. Først og fremst vil du indeksere hvilket som helst felt som ofte brukes i en WHERE-setning. Les mer om riktig indeksering av databasen.
