Jeg vil gerne have, at databasesystemet hjælper mig med at holde orden i data, så programmerne ikke behøver at gøre det. På den måde bliver programmerne - efter min mening - sikrere og mere koncise.
I modsætning her til står det synspunkt, at databasen sådan set bare er en stor spand, hvor man kan hælde semistrukturerede data i, og det med mindst muligt besvær. Integritetsregler er mest af alt i vejen, og i øvrigt så koster de vist også performance.
Når man opfatter databasen på den måde, så giver det sig selv, at det bliver programmernes ansvar selv at sikre sig, at der er orden i data. Det lægger en større byrde på omhu og på kvalitetssikring.
Selvom jeg har valgt side, så har begge synsvinkler faktisk hver i sær sin rimelighed. Er strukturen i rivende udvikling og/eller er skemaet til at overskue, så er det sandt, at integritetsregler mest af alt er i vejen. Men når kompleksiteten stiger, og når det er vigtigt at have konsistente data, så er det ofte nødvendigt at have databasesystemet som kustoden, som dels kan hjælpe med at vise vej, og dels kan afvise de værste unoder.
Kort sagt, så hjælper integriteretreglerne med fastholde viden om domænet.
I forhold til programmeringssprog, så er jeg typen, som har det bedst med sprog, som har en statisk typestruktur. Statisk typecheck gør det muligt at udtrykke ens forståelse af domænet præcist, og advarer en tidligt, hvis man - populært sagt - prøver at blande pærer og bananer.
I modsætning hertil står programmeringssprog med en dynamisk typestruktur. Hvis domæneforståelsen er under udvikling, og man i har tilstrækkeligt overblik og udviser fornøden omhu, så er statisk typecheck mest af alt en spændetrøje på kreativiteten.
Jeg kunne fortsætte, men i virkeligheden så vil jeg blive ganske skuffet, hvis I ikke allerede har gættet, at min pointe er, at der er tale en interessant parallel: integritetsregler i en database er en måde at udtrykke forretningsforståelse på, og det er typesystemet i et programmeringssprog også.
Min holdning burde også være klar: jeg vil hellere lade compileren sikre konsistensen, end at jeg vil bruge tid på at skrive og vedligeholde unittest, som i bund og grund kun gør det samme.
Alligevel må jeg erkende, at det kan blive belastende hele tiden at skulle bekræfte compileren i, at man godt kan huske, hvad der er pærer og hvad der der bananer. Rigtigt slemt bliver det, når man har noget kode, hvor man egentlig i bund og grund er lige glad med, om det er den ene eller den anden konkrete type - man tager bare imod pærer og giver pærer videre ... og viser de sig på et tidspunkt i virkeligheden at være bananer, så gør det ikke noget, bare man kan få og give dem videre uden at det bliver blandet sammen.
Tag f.eks. følgende lille stump Scala kode:
class Bowl {
def getAFruit = new Pear
def add(fruit: Pear) = "Added "+fruit.toString
}
case class Pear
case class Banana
object Mixer {
def mix(aBowl: Bowl, anotherBowl: Bowl) = {
val fruit = aBowl getAFruit;
anotherBowl add(fruit)
}
}Her er tale om skåle til een slags frugt, og en mixer, som tager et stykke frugt fra den slags skåle og lægger det over i en anden skål af samme slags. Og
grundlæggende set, så er mixeren faktisk lige glad med frugter - var det ikke lige fordi, at jeg havde kaldt metoder og variable noget frugtagtigt, så kunne det faktisk være hvad som helst.
Ændrer man skålen til at give og tage bananer i stedet, så virker mixeren stadig. Men prøver man at lave om på skålen, så den giver bananer og tager imod pærer, så brokker compileren sig, som den skal - så der er i virkeligheden et typecheck omme bagved - vi bliver bare hjulpet af typeinferensen til at glemme det for et øjeblik. Og sådan bør det også være - det ligner for mig nærmest noget af det gode fra begge verdener.
...og så for at lige at forgribe evt. kommentarer: Ja, det kunne modelleres mere præcist, f.eks. med anonyme typer - men det er helt anden snak.
