Ik heb een eon geleden een database-subschema gemaakt voor handlingunits (oké, ik overdrijf een beetje; het was echter ongeveer 20 jaar geleden). Gelukkig had het alleen te maken met eenvoudige massa, lengte, tijdsdimensies - niet temperatuur, of elektrische stroom, of helderheid, enz. Iets minder eenvoudig was de valutakant van het spel - er waren talloze verschillende manieren om tussen één valuta te converteren en een andere afhankelijk van de datum, valuta en periode waarover de omrekeningskoers geldig was. Dat werd apart van de fysieke eenheden afgehandeld.
Fundamenteel heb ik een tabel 'metingen' gemaakt met een 'id'-kolom, een naam voor de eenheid, een afkorting en een reeks dimensie-exponenten - één voor massa, lengte, tijd. Dit wordt gevuld met namen zoals 'volume' (lengte =3, massa =0, tijd =0), 'dichtheid' (lengte =3, massa =-1, tijd =0) - en dergelijke.
Er was een tweede tabel met eenheden, die een maat identificeerde en vervolgens de werkelijke eenheden die door een bepaalde meting werden gebruikt. Er waren bijvoorbeeld vaten en kubieke meters en allerlei andere relevante eenheden.
Er was een derde tabel die conversiefactoren tussen specifieke eenheden definieerde. Deze bestond uit twee eenheden en de multiplicatieve conversiefactor die eenheid 1 naar eenheid 2 converteerde. Het grootste probleem hierbij was het dynamisch bereik van de conversiefactoren. Als de conversie van U1 naar U2 1.234E+10 is, dan is het omgekeerde een vrij klein getal (8.103727714749e-11).
De opmerking van S.Lott over temperaturen is interessant - daar hebben we niet mee te maken gehad. Een opgeslagen procedure zou dat hebben aangepakt - hoewel het misschien lastig zou zijn om één opgeslagen procedure in het systeem te integreren.
Met het schema dat ik heb beschreven, konden de meeste conversies eenmaal worden beschreven (inclusief hypothetische eenheden zoals stadiën per twee weken, of minder hypothetische maar even obscure - buiten de VS - zoals acre-feet), en de conversies konden worden gevalideerd (bijvoorbeeld beide eenheden in de conversiefactortabel moesten dezelfde maat hebben). Het zou kunnen worden uitgebreid om de meeste andere eenheden aan te kunnen - hoewel de dimensieloze eenheden zoals hoeken (of vaste hoeken) enkele interessante problemen opleveren. Er was ondersteunende code die willekeurige conversies zou afhandelen - of een fout zou genereren wanneer de conversie niet kon worden ondersteund. Een reden voor dit systeem was dat de verschillende internationale aangesloten bedrijven hun gegevens in hun plaatselijk geschikte eenheden zouden rapporteren, maar het hoofdkantoorsysteem moest de originele gegevens accepteren en toch de resulterende geaggregeerde gegevens presenteren in eenheden die geschikt waren voor de managers - waarbij verschillende managers elk hadden hun eigen idee (op basis van hun nationale achtergrond en de duur van hun dienstplicht op het hoofdkwartier) over de beste eenheden voor hun rapporten.