Fortæl sandheden til din database

14. juni 2022, du lytter til DotNyt

I dag har jeg et lille tip som er at man skal fortælle sandheden til sin database. Det lyder banalt men alle udviklere har gennem tiderne løjet for deres databaser utallige gange og det har meget ofte givet dem problemer. Mange af problemerne oplever man først adskillige år senere, så det er ikke alle der når at mærke det på egen krop.

Forestil dig du udvikler en medlemsdatabase og på medlemmerne registrerer du om de ønsker at modtage gode tilbud på email. 9 ud af 10 udviklere vil nok gemme en boolean i databasen. False hvis de ikke vil modtage tilbud på mail og true hvis de gerne vil. Det er der egentligt ikke noget galt med.

Men hvad med de medlemmer som er kommet ind fra et eksternt system og derfor ikke har taget stilling til spørgsmål. De fleste udviklere vil registrere “false” for de brugere. Og det er jo ikke direkte forkert. Det er rigtigt at brugeren IKKE har givet tilsagn til at modtage tilbud på mail.

Men det er endnu mere præcist at indikere at de aldrig er blevet spurgt. De har hverken svaret ja eller nej, så det er et godt eksempel hvor man skal gemme “null” i databasen.

Man så 3 år senere gerne vil følge op og spørge dem som aldrig er blevet spurgt, så kan man ikke se det i databasen. Så det er et lille lavpraktisk eksempel på hvorfor det er vigtigt at man er meget præcis med de data man gemmer i databasen – og det er det jeg mener når jeg for sjov siger at man ikke skal lyve overfor sin database.

Et andet eksempel kan være et bookingsystem hvor man booker en tennisbane fra og til et bestemt tidspunkt. Hvis man booker en time fra 10 til 11, vil en uerfaren udvikler være meget fristet til at sætte sluttidspunktet til 10:59:59. Altså 1 sekund før 11. Det gør de måske for at forhindre tvivl om hvorvidt bookinger overlapper eller fordi de ellers får uventede resultater hvis de leder efter alle tider som overlapper med et bestemt tidsrum.

Men det er jo ikke korrekt. Banen lukker ikke et sekund før klokken 11. Hvis der endelig skal være lidt buffer mellem tiderne er det jo ikke et sekund. Så det passer simpelt hen ikke at sluttidspunktet er klokken 10:59:59. Sluttidspunktet er faktisk 11:00 så det er også det der skal stå i databasen.

Så må man med sandheden i hånden lave nogle gode features som tager hensyn til de kendsgerninger som er gemt i databasen. Det vil man for evigt takke sig selv for ved fremtidige features der ikke er tænkt på endnu, hvor 23:59:59 ikke giver mening. Det kan være en sammentælling af antal minutter per måned som pludselig giver et skævt tal.

Et sidste eksempel handler om navngivning. Det er så vigtigt at feltets navn passer med indholdet. Nybegyndere tager sig ikke de 2 minutter til at tænke grundigt over navnet, men selv meget dygtige og erfarne udviklere kan falde i en fælde hvor de bilder sig ind at de lige kan “rette det senere”.

Det kan f.eks. være sket hvis man troede man ville navne i fornavn og efternavn men senere fandt ud af det var smartere at gemme hele navnet i et felt og det gemmer man så bare i fornavn-feltet – fordi der er jo en deadline vi skal nå og så fixer vi det lige senere.

Men senere laver vi jo den næste fede feature og vender aldrig tilbage til noget der fungerer fint. Så der er kun ét tidspunkt hvor man kan rette et forkert navngivet felt og det er simpelthen det gode gamle “nu eller aldrig”.

Og hvis man vælger “aldrig” vil generationer af udviklere blive forvirrede og i tvivl om hvad feltet
indeholder.

Man det med navnene er nu bare en hygiejnefaktor – der hvor man virkelig kan komme i problemer er hvis man ikke er helt præcis med de data man gemmer. Det er svært at rette op på, for man har allerede features som er baseret på de forkerte data.

Så gør dig selv en stor tjeneste og fortæl sandheden til din database.