Når du som utvikler får en oppgave basert på eksisterende kode, må du møte mange utfordringer. En slik utfordring - oftere enn ikke den mest krevende - innebærer å forstå datamodellen til en applikasjon.

Du står normalt overfor forvirrende tabeller, visninger, kolonner, verdier, lagrede prosedyrer, funksjoner, begrensninger og utløsere som det tar lang tid å gi mening for deg. Og når de gjør det, begynner du å legge merke til mange måter å forbedre og dra nytte av den lagrede informasjonen på.

Hvis du er en erfaren utvikler, er sjansen stor for at du også vil legge merke til ting som kunne vært gjort bedre i begynnelsen, dvs. designfeil.

I denne artikkelen vil du lære om noen av vanlige dårlige fremgangsmåter for databasedesign, hvorfor de er dårlige, og hvordan du kan unngå dem.

Dårlig praksis nr. 1: Ignorer formålet med dataene

Data lagres for å bli konsumert senere, og målet er alltid å lagre dem og hente dem på den mest effektive måten. For å oppnå dette må databasedesigneren på forhånd vite hva dataene skal representere, hvordan skal de anskaffes og i hvilken hastighet, hvilket driftsvolum det vil være (dvs. hvor mye data som forventes), og til slutt , hvordan den skal brukes.

For eksempel vil et industrielt informasjonssystem der data samles inn manuelt hver dag ikke ha den samme datamodellen som et industrielt system der informasjon genereres i sanntid. Hvorfor? Fordi det er veldig annerledes å håndtere noen hundre eller tusenvis av poster per måned sammenlignet med administrere millioner av dem i samme periode. Spesielle hensyn må tas av designerne for å opprettholde databasens effektivitet og brukervennlighet, hvis datavolumene skal være store.

Men selvfølgelig er datavolum ikke det eneste aspektet å vurdere, siden formålet med dataene også påvirker normaliseringsnivået, datastrukturen, rekordstørrelsen og den generelle implementeringen av hele systemet.

Derfor, grundig kunnskap om formålet med datasystemet du oppretter, fører til hensyn til valg av databasemotor, enhetene du skal designe, rekordstørrelse og format og databasemotorprogrammer.

Å ignorere disse målene vil føre til design som er feil i grunnleggende, selv om de er strukturelt og matematisk korrekte.

Dårlig praksis nr. 2: Dårlig normalisering

Å designe en database er ikke en deterministisk oppgave; to databasedesignere kan følge alle reglene og normaliseringsprinsippene for et gitt problem, og i de fleste tilfeller vil de generere forskjellige dataoppsett. Dette er iboende for den kreative naturen til programvareteknikk. Imidlertid er det noen analyseteknikker som gir mening i alle tilfeller, og å følge dem er den beste måten å komme til en database som fungerer best.

Til tross for dette blir vi ofte møtt med databaser som ble designet på farten uten å følge de mest grunnleggende reglene for normalisering. Vi må være tydelige på det: Hver database bør i det minste normaliseres til tredje normalform, siden det er oppsettet som best representerer enhetene dine, og hvis ytelse vil være best balansert mellom spørring og innsetting-oppdatering-sletting av poster .

Hvis du snubler med bord som ikke overholder 3NF , 2NF, eller til og med 1NF, bør du vurdere å designe disse tabellene. Innsatsen du investerer i, vil lønne seg på veldig kort sikt.

Dårlig praksis nr. 3: Redundans

Svært relatert til forrige punkt, siden en av mål for normalisering er å redusere det, er overflødighet en annen dårlig praksis som dukker opp ganske ofte.

Redundante felt og tabeller er et mareritt for utviklere, siden de krever forretningslogikk for å holde mange versjoner av den samme informasjonen oppdatert. Dette er en overhead som kan unngås hvis normaliseringsregler følges grundig. Selv om redundans noen ganger kan virke nødvendig, må den bare brukes i veldig spesifikke tilfeller og være tydelig dokumentert for å bli tatt i betraktning i fremtidig utvikling.

Typiske dårlige effekter av redundans er en unødvendig økning i databasestørrelsen, data er utsatt for inkonsekvens og redusert effektivitet i databasen, men - enda viktigere, det kan føre til datakorrupsjon.

Dårlig praksis nr. 4: Dårlig referanseintegritet (begrensninger)

Referanseintegritet er et av de mest verdifulle verktøyene databasemotorer gir for å holde datakvaliteten på sitt beste. Hvis ingen begrensninger eller svært få begrensninger implementeres fra designfasen, vil dataintegriteten måtte stole helt på forretningslogikken, noe som gjør den utsatt for menneskelige feil.

Dårlig praksis nr. 5: Utnytter ikke DB-motorfunksjonene

Når du bruker en databasemotor (DBE), har du en kraftig programvare for datahåndteringsoppgavene dine som vil forenkle programvareutvikling og garantere at informasjon alltid er riktig, sikker og brukbar. En DBE tilbyr tjenester som:

• Visninger som gir en rask og effektiv måte å se på dataene dine på, normaliserer de vanligvis for spørringsformål uten å miste datakorrektheten.
• Indekser som hjelper til med å få raskere søk på tabeller.
• Aggregerte funksjoner som hjelper med å analysere informasjon uten programmering.
• Transaksjoner eller blokker med dataendrende setninger som alle blir utført og begått eller kansellert (rullet tilbake) hvis noe uventet oppstår, og dermed holder informasjonen i en evig korrekt tilstand.
• Låser som holder data trygge og korrekte mens transaksjoner utføres.
• Lagrede prosedyrer som gir programmeringsfunksjoner for å tillate komplekse datahåndteringsoppgaver.
• Funksjoner som tillater sofistikerte beregninger og datatransformasjoner.
• Begrensninger som hjelper deg med å garantere datakorighet og unngå feil.
• Utløsere som hjelper med å automatisere handlinger når hendelser skjer på dataene.
• Command optimizer (utførelsesplanlegger) som går under panseret, og sørger for at hver setning blir utført på sitt beste og holder utførelsesplanene for fremtidige anledninger. Dette er en av de beste grunnene til å bruke visninger, lagrede prosedyrer og funksjoner, siden utførelsesplanene deres holdes permanent i DBE.

Å ikke vite eller ignorere disse evnene vil føre utviklingen til en ekstremt usikker vei og helt sikkert til bugs og fremtidige problemer.

Dårlig praksis nr. 6: sammensatte primærnøkler

Dette er liksom et kontroversielt poeng, siden mange databasedesignere i dag snakker om å bruke et helt tall automatisk generert felt som primærnøkkel i stedet for en sammensatt definert av kombinasjonen av to eller flere felt. Dette er for tiden definert som 'beste praksis', og personlig er jeg tilbøyelig til å være enig i det.

Dette er imidlertid bare en konvensjon, og selvfølgelig tillater DBE definisjonen av sammensatt primær nøkler, som mange designere mener er uunngåelige. Derfor, som med redundans, er sammensatte primærnøkler en designbeslutning.

Vær imidlertid oppmerksom på at hvis tabellen din med en sammensatt primærnøkkel forventes å ha millioner av rader, kan indeksen som styrer den sammensatte nøkkelen vokse opp til et punkt der ytelsen til CRUD-operasjonen er veldig svekket. I så fall er det mye bedre å bruke en enkel heltall ID primærnøkkel hvis indeks vil være kompakt nok og etablere de nødvendige DBE-begrensningene for å opprettholde unikhet.

Dårlig praksis nr. 7: Dårlig indeksering

Noen ganger vil du ha en tabell du trenger å spørre etter mange kolonner. Når tabellen vokser, vil du legge merke til at SELECTs på disse kolonnene reduseres. Hvis tabellen er stor nok, vil du logisk tenke å lage en indeks på hver kolonne som du bruker for å få tilgang til denne tabellen bare for å finne nesten umiddelbart at ytelsen til SELECTs forbedres, men INSERTs, UPDATEs og DELETEs faller. Dette skyldes selvfølgelig at indekser må holdes synkronisert med tabellen, noe som betyr massiv overhead for DBE. Dette er et typisk tilfelle av overindeksering som du kan løse på mange måter; For eksempel, hvis du bare har en indeks på alle kolonnene som er forskjellig fra primærnøkkelen du bruker for å spørre om tabellen, kan det å gi bedre ytelse i alle CRUD-operasjoner enn en indeks per kolonne hvis du bestiller disse kolonnene fra den mest brukte til den minste.

På den annen side vil det å ha en tabell uten indeks på kolonner som brukes til å spørre, føre til dårlig ytelse på SELECTs, som vi alle vet.

Indekseffektivitet avhenger også av og til av kolonnetypen; indekser på INT-kolonner viser best mulig ytelse, men indekser på VARCHAR, DATE eller DECIMAL (hvis det noen gang gir mening) er ikke like effektive. Denne betraktningen kan til og med føre til redesign av tabeller som må nås med best mulig effektivitet.

Derfor er indeksering alltid en delikat beslutning, ettersom for mye indeksering kan være like dårlig som for lite, og fordi datatypen til kolonnene som skal indekseres på har stor innflytelse på det endelige resultatet.

Dårlig praksis nr. 8: Dårlige navnekonvensjoner

Dette er noe som programmerere alltid sliter med når de står overfor en eksisterende database: å forstå hvilken informasjon som er lagret i den med navnene på tabeller og kolonner fordi det ofte ikke er noen annen måte.

Tabellnavnet må beskrive hvilken enhet den har, og hvert kolonnenavn må beskrive hvilken informasjon den representerer. Dette er enkelt, men det begynner å bli komplisert når bord må forholde seg til hverandre. Navn begynner å bli rotete, og verre, hvis det er forvirrende navngivningskonvensjoner med ulogiske normer (som for eksempel 'kolonnenavnet må være 8 tegn eller mindre'). Den endelige konsekvensen er at databasen blir uleselig.

Derfor er en navnekonvensjon er alltid nødvendig hvis databasen forventes å vare og utvikle seg med applikasjonen den støtter, og her er noen retningslinjer for å etablere en kortfattet, enkel og lesbar:

• Ingen begrensninger på størrelsen på tabellen eller kolonnen. Det er bedre å ha et beskrivende navn enn et akronym som ingen husker eller forstår.
• Navn som er like har samme betydning. Unngå å ha felt som har samme navn, men med forskjellige typer eller betydninger; dette vil være forvirrende før eller siden.
• Ikke vær overflødig med mindre det er nødvendig. For eksempel, i tabellen 'Element', er det ikke nødvendig å ha kolonner som 'ItemName', 'PriceOfItem' eller lignende navn. “Navn” og “Pris” er nok.
• Vokt deg for DBE reserverte ord. Hvis en kolonne skal kalles 'Indeks', som er et SQL-reservert ord, kan du prøve å bruke en annen som 'Indeksnummer'.
• Hvis du holder deg til den enkle primærnøkkelregelen (automatisk generert heltall), kan du gi den navnet “Id” i hver tabell.
• Hvis du blir med i en annen tabell, definerer du den nødvendige fremmednøkkelen som et heltall, kalt “Id” etterfulgt av navnet på den sammenføyde tabellen (f.eks. IdItem).
• Hvis du navngir begrensninger, bruk et prefiks som beskriver begrensningen (f.eks. “PK” eller “FK”), etterfulgt av navnet på tabellen eller tabellene som er involvert. Å bruke understreker (“_”) sparsomt bidrar til å gjøre ting mer lesbare.
• For å gi navn til indekser, bruk prefikset “IDX” etterfulgt av tabellnavnet og kolonnen eller kolonnene i indeksen. Bruk også 'UNIK' som et prefiks eller suffiks hvis indeksen er unik, og understreker der det er nødvendig.

Det er mange retningslinjer for navngivning av databaser på internett som vil skinne mer lys over dette veldig viktige aspektet ved databasedesign, men med disse grunnleggende kan du i det minste komme til en lesbar database. Det som er viktig her er ikke størrelsen eller kompleksiteten til navngivningsretningslinjene, men din konsistens i å følge dem!

Noen endelige merknader

Database design er en kombinasjon av kunnskap og erfaring; programvareindustrien har utviklet seg mye siden de første dagene. Heldigvis er det nok kunnskap tilgjengelig for å hjelpe databasedesignere oppnå de beste resultatene.

Det er god databasedesign retningslinjer over hele internett så vel som dårlig praksis og ting å unngå i databasedesign. Bare velg og hold deg til det.

Og ikke glem, det er bare gjennom eksperimentering, feil og suksesser du lærer, så fortsett og start nå.