Jeg producerede et database-underskema til håndtering af enheder for en aeon siden (okay, jeg overdriver lidt; det var dog omkring 20 år siden). Heldigvis skulle det kun beskæftige sig med simpel masse, længde, tidsdimensioner - ikke temperatur, eller elektrisk strøm, eller lysstyrke osv. Ret mindre enkel var valutasiden af spillet - der var et utal forskellige måder at konvertere mellem en valuta og en anden afhængig af dato, valuta og periode, hvor konverteringskursen var gyldig. Det blev håndteret adskilt fra de fysiske enheder.
Grundlæggende oprettede jeg en tabel 'mål' med en 'id'-kolonne, et navn til enheden, en forkortelse og et sæt dimensionseksponenter - hver for masse, længde, tid. Dette bliver udfyldt med navne som "volumen" (længde =3, masse =0, tid =0), "densitet" (længde =3, masse =-1, tid =0) - og lignende.
Der var en anden tabel med enheder, som identificerede et mål og derefter de faktiske enheder, der blev brugt af en bestemt måling. For eksempel var der tønder og kubikmeter og alle mulige andre enheder af relevans.
Der var en tredje tabel, der definerede konverteringsfaktorer mellem specifikke enheder. Denne bestod af to enheder og den multiplikative omregningsfaktor, der konverterede enhed 1 til enhed 2. Det største problem her var det dynamiske område af konverteringsfaktorerne. Hvis konverteringen fra U1 til U2 er 1.234E+10, så er det omvendte et ret lille tal (8.103727714749e-11).
Kommentaren fra S.Lott om temperaturer er interessant - dem behøvede vi ikke at forholde os til. En lagret procedure ville have løst det - selvom det kunne have været vanskeligt at integrere en lagret procedure i systemet.
Det skema, jeg beskrev, gjorde det muligt at beskrive de fleste konverteringer én gang (inklusive hypotetiske enheder såsom furlongs pr. fjorten dage, eller mindre hypotetiske, men lige så obskure - uden for USA - som acre-feet), og konverteringerne kunne valideres (f.eks. både enheder i omregningsfaktortabellen skulle have samme mål). Det kunne udvides til at håndtere de fleste af de andre enheder - selvom de dimensionsløse enheder såsom vinkler (eller solide vinkler) giver nogle interessante problemer. Der var understøttende kode, der kunne håndtere vilkårlige konverteringer - eller generere en fejl, når konverteringen ikke kunne understøttes. En grund til dette system var, at de forskellige internationale tilknyttede virksomheder ville rapportere deres data i deres lokalt bekvemme enheder, men HQ-systemet skulle acceptere de originale data og alligevel præsentere de resulterende aggregerede data i enheder, der passede til lederne - hvor forskellige ledere hver især havde deres egen idé (baseret på deres nationale baggrund og varighed af tjeneste i hovedkvarteret) om de bedste enheder til deres rapporter.