Oavsett huruvida du arbetar med en databas som rymmer hundratals poster eller miljontals poster, är korrekt databasdesign alltid viktigt. Det kommer inte bara att göra det lättare att hämta informationen, det kommer också att förenkla databasens expansion i framtiden. Tyvärr är det lätt att falla i ett fåtal fällor som kan göra det svårt i framtiden.
Det finns hela böcker skrivna om ämnet normalisering av en databas, men om du helt enkelt undviker de vanliga misstag som visas här kommer du vara på rätt väg till bra databasdesign.
Databasfel # 1: Repeterande fält i ett bord
En grundläggande tumregel för bra databasdesign är att känna igen upprepande data och att sätta de upprepande kolumnerna i sitt eget bord. Upprepande fält i en tabell är vanliga för dem som har kommit från världen av kalkylblad, men medan kalkylblad tenderar att vara platt genom design bör databaser vara relationella. Det är som att gå från 2D till 3D.
Lyckligtvis är repetitiva fält oftast lätta att upptäcka. Ta en titt på denna tabell:
| OrderID | product1 | product2 | Product3 |
| 1 | Nallar | Gelébönor | |
| 2 | Gelébönor |
Vad händer när en order innehåller fyra produkter? Vi skulle behöva lägga till ett annat fält i tabellen för att stödja mer än tre produkter. Och om vi har byggt upp en klientprogram runt bordet för att hjälpa oss att mata in data, kan vi behöva ändra det med det nya produktfältet. Och hur hittar vi alla beställningar med Jellybeans i ordern? Vi skulle vara tvungna att fråga varje produktfält i tabellen med ett SQL-uttalande som kan se ut: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ELLER Product2 = 'Jelly Beans' ELLER Product3 = 'Jelly Beans'.
I stället för att ha ett enda bord som fyller all information tillsammans, borde vi ha tre tabeller som var och en innehåller en distinkt information. I det här exemplet vill vi ha ett orderbord med information om själva beställningen, en produkttabell med alla våra produkter och en ProductOrders-tablett som kopplade produkter till beställningen.
| OrderID | Kundnummer | Orderdatum | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Serienummer | Produkt | Räkna |
| 1 | Nallar | 1 |
| 2 | Gelébönor | 100 |
| ProductOrderID | Serienummer | OrderID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Lägg märke till hur varje tabell har sitt eget unika ID-fält. Detta är den primära nyckeln. Vi länkar tabeller med ett primärtangentvärde som en främmande nyckel i en annan tabell. Läs mer om primära nycklar och främmande nycklar.
Databasfel # 2: Bädda in ett bord i ett bord
Detta är ett annat vanligt misstag, men det står inte alltid lika mycket som repetitiva fält. När du designar en databas vill du se till att alla data i ett bord hänför sig till sig själv. Det är som barnets spel om att upptäcka vad som är annorlunda. Om du har en banan, en jordgubbe, en persika och en tv-apparat, hörs TV-apparaten säkert någon annanstans.
På samma sätt, om du har en tabell med säljare, bör all information i den tabellen särskilt relatera till den säljaren. Eventuell extra information som inte är unik för den säljaren kan höra någon annanstans i din databas.
| SalesID | Först | Sista | Adress | Telefonnummer | Kontor | OfficeNumber |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Smed | 504 2nd Street, New York, NY | (211) 122-1821 | New York (öst) | (211) 855-4541 |
| 3 | Joe | Socken | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Medan den här tabellen kan se ut så är den helt relaterad till den enskilda försäljaren, det har faktiskt ett bord inbäddat i bordet. Lägg märke till hur Office och OfficeNumber upprepas med "Austin Downtown". Vad händer om ett telefonnummer ändras? Du skulle behöva uppdatera en hel uppsättning data för ett enda informationsbyte, vilket aldrig är bra. Dessa fält ska flyttas till sitt eget bord.
| SalesID | Först | Sista | Adress | Telefonnummer | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Smed | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Socken | 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 |
Denna typ av design ger dig också möjlighet att lägga till ytterligare information till kontorsbordet utan att skapa en mardröm av rodnad i försäljningsbordet. Föreställ dig hur mycket arbete det är att helt enkelt hålla reda på gatuadressen, staden, staten och postnumret om all sådan information var i försäljningsbordet!
Databasfel nr 3: Sätta två eller flera bitar av information i ett enda fält
Inbäddning av kontorsinformationen i säljpersonalbordet var inte det enda problemet med den databasen. Adressfältet innehöll tre bitar av information: gatuadressen, staden och staten. Varje fält i databasen bör endast innehålla en enda information. När du har flera bitar av information i ett enda fält kan det bli svårare att fråga databasen för information.
Till exempel, om vi ville köra en fråga på alla säljare från Austin? Vi skulle behöva söka inom adressfältet, vilket inte bara är ineffektivt, men kan returnera dålig information. Trots allt, vad händer om någon bodde på Austin Street i Portland, Oregon?
Så här ska bordet se ut:
| SalesID | Först | Sista | Adress 1 | Adress 2 | Stad | stat | Blixtlås | Telefon |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Smed | 504 2: e St | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Socken | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Det finns ett par saker att notera här.Först, "Adress1" och "Adress2" verkar falla under det repeterande fältet misstag.
Men i det här fallet hänvisar de till separata datauppgifter som direkt hänför sig till säljaren snarare än en upprepad grupp av data som borde gå i sitt eget bord.
Också, som ett bonusfel för att undvika, märka hur formateringen för telefonnumret har tagits bort från bordet. Du bör undvika att lagra fältformat när det är möjligt. När det gäller telefonnummer finns det flera sätt att skriva ett telefonnummer: 215-555-5858 eller (215) 555-5858. Detta skulle göra att söka efter en säljare via sitt telefonnummer eller göra en sökning av säljare i samma riktnummer svårare.
Databasfel nr 4: Använd inte en korrekt primär nyckel
I de flesta fall vill du använda ett automatiskt inkrementellt nummer eller något annat genererat nummer eller alfanumerisk för din primära nyckel. Du bör undvika att använda någon faktisk information för primärnyckeln, även om det låter som om det skulle göra en bra identifierare.
Vi har till exempel alla våra egna personnummer, så det kan vara bra att använda personnummeret för en anställd databas. Men medan det är sällsynt är det möjligt att även ett socialt säkerhetsnummer ändras, och vi vill aldrig ha vår primära nyckel att förändras.
Och det är problemet med att använda aktuell information som ett nyckelvärde. Det kan förändras.
Databasfel nr 5: Använd inte namngivningskonvention
Det här kanske inte låter som en stor sak när du börjar börja utforma din databas, men när du väl har skrivit frågor mot databasen för att hämta information, kommer det att finnas en namngivningskonvention som du kan memorera fältnamn.
Tänk dig hur mycket svårare den processen skulle vara om namnen lagrades som Förnamn, LastName i ett bord och förnamn, sista namn i en annan tabell.
De två mest populära namngivningskonventionerna kapitaliserar första bokstaven i varje ord i fältet eller skiljer ord med en understrykning. Du kan också se några utvecklare aktivera första bokstaven i varje ord utom det första ordet: firstName, lastName.
Du kommer också att bestämma dig för att använda singulära tabellnamn eller flertalsnamn. Är det ett orderbord eller ett orderbord? Är det ett kundtabell eller kunderbord? Återigen vill du inte fastna med en beställningsbord och ett kundbord.
Namnkonventionen du väljer är inte lika viktig som processen att faktiskt välja och hålla sig till en namngivningskonvention.
Databasfel nr 6: Felaktig indexering
Indexering är en av de svåraste sakerna att få rätt, speciellt för de nya på databasdesign. Alla primära nycklar och utländska nycklar ska indexeras. Det här är det som länkar tabellerna tillsammans, så utan ett index kommer du att se mycket dålig prestanda ur din databas.
Men vad som ofta saknas är de andra fälten. Dessa är "WHERE" -fälten. Om du ofta kommer att begränsa din sökning genom att använda ett fält i en WHERE-klausul, vill du tänka på att sätta ett index på det fältet. Men du vill inte alltför indexera tabellen, vilket också kan skada prestanda.
Hur man bestämmer sig Detta är en del av tekniken för databasdesign. Det finns inga hårda gränser för hur många index du borde lägga på ett bord. I första hand vill du indexera vilket fält som ofta används i en WHERE-klausul. Läs mer om korrekt indexering av din databas.
