Potensielle problemområder i multibare SQL-databaser - dummies

Dataintegritet er utsatt for angrep fra en rekke kvartaler. Noen av disse problemene oppstår bare i multitabile SQL-databaser; andre kan skje selv i databaser som bare inneholder et enkelt bord. Du vil gjenkjenne og minimere alle disse potensielle truslene.

Dårlige inngangsdata

Kildedokumenter eller datafiler du bruker til å fylle databasen din, kan inneholde dårlige data. Disse dataene kan være en ødelagt versjon av de riktige dataene, eller det kan ikke være de dataene du vil ha. En intervallkontroll forteller om dataene har domeneintegritet.

Denne typen kontroll tar noen - men ikke alle - problemer. For eksempel er feil feltverdier som er innenfor akseptabelt område - men fortsatt feil - ikke identifisert som problemer.

Operatørfeil

Kildedataene dine kan være riktige, men dataoppføringsoperatøren kan feilaktig transkribere dataene. Denne typen feil kan føre til de samme problemene som dårlige inngangsdata. Noen av løsningene er de samme. Range sjekker hjelp, men de er ikke idiotsikker. En annen løsning er å få en andre operatør til å validere alle dataene selvstendig.

Denne tilnærmingen er kostbar fordi uavhengig validering tar to ganger antall personer og to ganger tiden. Men i enkelte tilfeller hvor dataintegritet er kritisk, kan ekstra innsats og utgifter vise seg å være verdt.

Mekanisk svikt

Hvis du opplever en mekanisk feil, for eksempel en diskulykke, kan dataene i tabellen bli ødelagt. Gode ​​sikkerhetskopier er ditt hovedforsvar mot dette problemet.

Malice

Vurder muligheten for at noen kan vil for å ødelegge dataene dine. Din første forsvarslinje er å nekte databasetilgang til alle som kan ha en ondsinnet hensikt og å begrense autoriserte brukere, slik at de bare får tilgang til de dataene de trenger. Ditt andre forsvar er å opprettholde data backup på et trygt sted. Gjenta periodisk sikkerhetsfunksjonene i installasjonen din. Å være litt paranoid gjør ikke vondt.

Data redundans

Data redundans - de samme datapunktene som oppdrar seg på flere steder - er et stort problem med den hierarkiske databasemodellen, men problemet kan også plage relasjonsdatabaser. Ikke bare reduserer lagringsplassen for slike redundanser og reduserer behandlingen, men det kan også føre til alvorlig dataforstyrrelse.

Hvis du lagrer det samme dataelementet i to forskjellige tabeller i en database, kan elementet i en av disse tabellene endres, mens det tilsvarende elementet i den andre tabellen forblir det samme.Denne situasjonen genererer en avvik, og du kan ikke ha mulighet til å bestemme hvilken versjon som er riktig. Det er en god grunn til å holde data redundans til et minimum.

Selv om det er nødvendig med en viss redundans for primærnøkkelen til ett bord for å fungere som en fremmednøkkel i en annen, bør du prøve å unngå gjentagelse av dataelementer utover det.

Når du eliminerer de fleste redundans fra en databasedesign, kan du oppdage at ytelsen nå er uakseptabel. Operatører bruker ofte en viss redundans for å øke hastigheten på behandlingen.

En vanlig praksis er å i utgangspunktet designe en database med liten redundans og med høy grad av normalisering, og etter å ha funnet ut at viktige applikasjoner går sakte, velger man selektivt redundans og denormaliserer. Nøkkelordet her er selektivt.

Redundansen som du legger til igjen må ha et bestemt formål, og fordi du er klar over både redundansen og risikoen den representerer, tar du passende tiltak for å sikre at redundansen ikke forårsaker flere problemer enn det løser.

Når du overskrider kapasiteten til DBMS

, kan et databasesystem fungere ordentlig i mange år, og deretter begynne å oppleve intermitterende feil som blir stadig mer alvorlige. Dette kan være et tegn på at du nærmer deg et av systemets kapasitetsgrenser. Det er jo grenser for antall rader som et bord kan ha. Det er også grenser for kolonner, begrensninger og ulike andre databasegenskaper.

Kontroller gjeldende størrelse og innhold i databasen din mot spesifikasjonene som er oppført i dokumentasjonen til DBMS. Hvis du er nær grensen i et hvilket som helst område, bør du vurdere å oppgradere til et system med høyere kapasitet. Eller du vil kanskje arkivere eldre data som ikke lenger er aktive, og deretter slette den fra databasen.