Sentraliser din dataintegritet

Systemer (dvs. databaser) som håndterer sin egen dataintegritet høres ut som sunn fornuft, og i enkle scenarioer er det sunn fornuft. Men når forretningsreglene blir komplekse, er det vanskeligere å validere dataene på et sentralt sted.

Når et system (dvs. en database) ikke lenger kan håndheve formen på dataene, må noe annet ta over. Når kan dette skje?

Telefonnummerformatet i USA er (områdekode) (prefiks) – (nummer), her er et eksempel: (734) 555-3212. Vi vil snakke om databasen i denne artikkelen for enkelhets skyld, men datalageret trenger ikke å være en database.

Telefonnumre i USA har alltid ti sifre (vi ignorerer det internasjonale sifferet). Telefonnumre kan komme i en rekke formater:

• xxx.xxx.xxxx
• xxx-xxx-xxxx
• (xxx) xxx-xxxx
• (xxx) xxx.xxxx

De fleste databaser er begrenset til datatyper (dvs. tall, strenger, datoer, osv.) og støtter ikke formatering. Mange applikasjoner velger å bruke string-datatypen for å lagre telefonnummeret. Men string-datatypen aksepterer ALLE strenger. For å sikre at telefonnummeret er gyldig, trenger vi et ekstra lag med validering.

I en enkelt applikasjon som kobler til en enkelt database, blir datavalidering vanligvis håndhevet i applikasjonen.

Når arkitekturen din vokser til to eller flere applikasjoner som deler en database, kan to ting skje:

1. Hver applikasjon har sin egen datavalidering:

2. Det er en sentral tjeneste som applikasjonene kaller for å validere dataene og lagre dataene:

Risikoen ved datavalidering på flere steder er at valideringene kan være ute av synk. Et gyldig format for én applikasjon er kanskje ikke gyldig i en annen applikasjon. I verste fall vil et dårlig format kaste en feil eller, i ekstreme tilfeller, krasje applikasjonen.

Det beste tilfellet er å sentralisere datavalideringen slik at formatet som lagres i databasen er konsistent for hele organisasjonen. Det finnes unntak, selvfølgelig, og jeg antar at flere applikasjoner leser og skriver til en delt database.