Huvud ny & nästa Databasdesign: vanliga misstag att undvika
ny & nästa

Databasdesign: vanliga misstag att undvika

Databasdesign: vanliga misstag att undvika
Anonim

  • 5G trådlös
  • 3D-design
  • 3d-utskrivning
  • Smart hem
  • Raspberry Pi
  • av Daniel Nations

    Daniel Nations har varit en teknisk journalist sedan 1994. Hans arbete har dykt upp i Computer Currents, The Examiner, The Spruce och andra publikationer.

    Oavsett om du arbetar med en databas som har hundratals poster eller miljoner poster, är korrekt databasdesign alltid viktigt. Inte bara kommer det att hämta informationen mycket lättare, det kommer också att förenkla utvidgningen av databasen i framtiden. Tyvärr är det lätt att falla i några fällor som kan göra det svårt i framtiden.

    Det finns hela böcker skrivna om ämnet att normalisera en databas, men om du helt enkelt undviker de vanliga misstag som visas här kommer du att vara på rätt väg till bra databasdesign.

    Databasfel nr 1: Upprepa fält i en tabell

    En grundläggande tumregel för god databasdesign är att känna igen upprepade data och att lägga de upprepande kolumnerna i sin egen tabell. Upprepa fält i en tabell är vanligt för dem som har kommit från världen av kalkylark, men medan kalkylblad tenderar att vara platt av design, bör databaser vara relationella. Det är som att gå från 2D till 3D.

    Lyckligtvis är repetitiva fält vanligtvis lätta att upptäcka. Titta bara på det här bordet:

    OrderIDproduct1product2Product3
    1NallarJelly Beans
    2Jelly Beans

    Vad händer när en beställning innehåller fyra produkter? Vi måste lägga till ett annat fält i tabellen för att stödja mer än tre produkter. Och om vi har byggt en klientapplikation runt bordet för att hjälpa oss att mata in data, kan vi behöva ändra den med det nya produktfältet. Och hur hittar vi alla beställningar med Jellybeans i ordningen? Vi skulle tvingas fråga varje produktfält i tabellen med ett SQL-uttalande som kan se ut: VÄLJ * FRÅN Produkter VAR Produkt1 = "Jelly Beans" ELLER Product2 = "Jelly Beans" ELLER Product3 = "Jelly Beans".

    Istället för att ha ett enda bord som fyller all information tillsammans, bör vi ha tre tabeller som var och en har en distinkt informationsdel. I det här exemplet vill vi ha en beställningstabell med information om själva beställningen, en produkttabell med alla våra produkter och en produktOrders-tablett som kopplade produkter till beställningen.

    OrderIDKundnummerOrderdatumTotal
    171/24/1719, 99
    291/25/1724, 99

    SerienummerProduktRäkna
    1Nallar1
    2Jelly Beans100

    ProductOrderIDSerienummerOrderID
    10111
    10221

    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 genom att använda ett primärt nyckelvärde som en utländsk nyckel i en annan tabell. Läs mer om primärnycklar och utländska nycklar.

    Databasfel nr 2: Bädda in en tabell i en tabell

    Detta är ytterligare ett vanligt misstag, men det sticker inte alltid ut lika mycket som repetitiva fält. När du utformar en databas vill du se till att alla data i en tabell hänför sig till sig själv. Det är som barnets spel om att se vad som är annorlunda. Om du har en banan, en jordgubbe, en persika och en tv-apparat hör TV-apparaten troligen någon annanstans.

    På samma sätt, om du har en tabell med säljare, bör all information i tabellen specifikt relatera till den säljaren. All extra information som inte är unik för den säljaren kan tillhöra någon annanstans i din databas.

    SalesIDFörstSistaAdressTelefonnummerKontorOfficeNumber
    1SamElliot118 Main St, Austin, TX(215) 555-5858Austin centrum(212) 421-2412
    2AliceSmed504 2nd Street, New York, NY(211) 122-1821New York (East)(211) 855-4541
    3JoeSocken428 Aker St, Austin, TX(215) 545-5545Austin centrum(212) 421-2412

    Även om den här tabellen kan se ut som om den är relaterad till den enskilda säljaren, har den faktiskt ett bord inbäddat i tabellen. Lägg märke till hur Office och OfficeNumber upprepas med "Austin Downtown". Vad händer om ett kontortelefonnummer ändras? Du måste uppdatera en hel uppsättning data för en enda informationsändring, vilket aldrig är bra. Dessa fält bör flyttas till sitt eget bord.

    SalesIDFörstSistaAdressTelefonnummerOfficeID
    1SamElliot118 Main St, Austin, TX(215) 555-58581
    2AliceSmed504 2nd Street, New York, NY(211) 122-18212
    3JoeSocken428 Aker St, Austin, TX(215) 545-55451

    OfficeIDKontorOfficeNumber
    1Austin centrum(212) 421-2412
    2New York (East)(211) 855-4541

    Denna typ av design ger dig också möjlighet att lägga till ytterligare information till Office-bordet utan att skapa en mardröm av röran i säljpersonabellen. Föreställ dig hur mycket arbete det skulle vara att helt enkelt hålla reda på gatuadressen, staden, staten och postnumret om all den informationen fanns i säljpersonabellen!

    Databasfel nr 3: Lägga två eller flera informationsbitar i ett enda fält

    Att bädda in kontorsinformationen i säljpersonabellen var inte det enda problemet med den databasen. Adressfältet innehöll tre information: gatuadressen, staden och staten. Varje fält i databasen bör bara innehålla en enda information. När du har flera informationsdelar 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, som inte bara är ineffektivt utan kan returnera dålig information. Vad händer trots allt om någon bodde på Austin street i Portland, Oregon?

    Så här ska bordet se ut:

    SalesIDFörstSistaAdress 1Adress 2StadstatBlixtlåsTelefon
    1SamElliot118 Main StAustinTX787202155555858
    2AliceSmed504 2: a StNew YorkNY100222111221821
    3JoeSocken428 Aker StApt 304AustinTX78.7162155455545

    Det är ett par saker att notera här. Först verkar "Adress1" och "Adress2" falla under det repetitiva fältfelet. I detta fall hänvisar de dock till separata uppgifter som hänför sig direkt till säljaren snarare än en upprepande grupp data som borde gå i sin egen tabell.

    Som ett bonusfel att undvika, lägg märke till hur formateringen för telefonnumret har tagits bort från bordet. Du bör undvika att lagra fältformatet 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 det svårare att söka efter en säljare efter deras telefonnummer eller göra en sökning av säljare i samma riktnummer.

    Databasfel nr 4: använder inte en korrekt primärnyckel

    I de flesta fall vill du använda ett automatiskt inkrementeringsnummer eller något annat genererat nummer eller alfanumeriskt för din primära nyckel. Du bör undvika att använda någon faktisk information för den primära nyckeln, även om det låter som om det skulle göra en bra identifierare.

    Till exempel har vi vårt eget individuella personnummer, så det kan låta som en bra idé att använda personnummer för en anställd databas. Men även om det är sällsynt är det möjligt att även ett personnummer ändras, och vi vill aldrig att vår primära nyckel förändras.

    Och det är problemet med att använda faktisk information som ett nyckelvärde. Det kan förändras.

    Databasfel nr 5: använder inte en namnkonvention

    Det här kanske inte låter som en stor sak när du först började designa din databas, men när du väl har kommit till att skriva frågor mot databasen för att hämta information kommer det att hjälpa dig att namnge fältnamn när du namnger ett namn. Föreställ dig hur mycket svårare processen skulle vara om namn lagrades som Förnamn, Efternamn i en tabell och förnamn, efternamn i en annan tabell.

    De två mest populära namnkonventionerna är att använda den första bokstaven i varje ord i fältet eller separera ord med en understruk. Du kanske också ser några utvecklare som använder den första bokstaven i varje ord förutom det första ordet: firstName, lastName.

    Du kommer också att vilja besluta om att använda enkla tabellnamn eller flertabellnamn. Är det en beställningstabell eller en beställningstabell? Är det ett kundtabell eller kundtabell? Återigen vill du inte sitta fast vid en ordertabell och ett kundtabell.

    Namnkonventionen du väljer är inte lika viktig som processen att faktiskt välja och hålla sig till ett namnkonvention.

    Databasfel nr 6: Felaktig indexering

    Indexering är en av de svåraste sakerna att få rätt, särskilt för de nya i databasdesign. Alla primära nycklar och utländska nycklar ska indexeras. Det här är vad som länkar tabeller tillsammans, så utan index kommer du att se mycket dålig prestanda ur din databas.

    Men det som alltför ofta missas är de andra fälten. Dessa är "VAR" -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 fundera på att sätta ett index på det fältet. Du vill emellertid inte överdrivet indexera tabellen, vilket också kan skada prestanda.

    Hur bestämmer jag? Detta är en del av konsten med databasdesign. Det finns inga hårda gränser för hur många index du ska lägga på ett bord. I första hand vill du indexera alla fält som ofta används i en WHERE-klausul. Läs mer om att korrekt indexera din databas.