Jag tog fram ett databasunderschema för hantering av enheter för en aeon sedan (okej, jag överdriver något, men det var ungefär 20 år sedan). Lyckligtvis hade det bara att göra med enkel massa, längd, tidsdimensioner - inte temperatur, eller elektrisk ström, eller ljusstyrka, etc. Ganska mindre enkel var valutasidan av spelet - det fanns en myriad olika sätt att konvertera mellan en valuta och en annan beroende på datum, valuta och period under vilken omräkningskursen var giltig. Det hanterades separat från de fysiska enheterna.
I grund och botten skapade jag en tabell "mått" med en "id"-kolumn, ett namn på enheten, en förkortning och en uppsättning dimensionsexponenter - en vardera för massa, längd, tid. Detta fylls med namn som "volym" (längd =3, massa =0, tid =0), "densitet" (längd =3, massa =-1, tid =0) - och liknande.
Det fanns en andra tabell med enheter, som identifierade ett mått och sedan de faktiska enheter som användes av ett visst mått. Till exempel fanns det fat och kubikmeter och alla möjliga andra enheter av relevans.
Det fanns en tredje tabell som definierade omvandlingsfaktorer mellan specifika enheter. Denna bestod av två enheter och den multiplikativa omräkningsfaktorn som omvandlade enhet 1 till enhet 2. Det största problemet här var omräkningsfaktorernas dynamiska omfång. Om omvandlingen från U1 till U2 är 1,234E+10, är inversen ett ganska litet tal (8.103727714749e-11).
Kommentaren från S.Lott om temperaturer är intressant - vi behövde inte ta itu med dem. En lagrad procedur skulle ha åtgärdat det - även om det kan ha varit svårt att integrera en lagrad procedur i systemet.
Schemat jag beskrev gjorde det möjligt för de flesta konverteringar att beskrivas en gång (inklusive hypotetiska enheter som furlongs per fjorton dagar, eller mindre hypotetiska men lika obskyra sådana - utanför USA - som tunnland), och omvandlingarna kunde valideras (till exempel både enheter i omräkningsfaktortabellen måste ha samma mått). Den skulle kunna utökas till att hantera de flesta andra enheter - även om de dimensionslösa enheterna som vinklar (eller heldragna vinklar) ger några intressanta problem. Det fanns stödjande kod som skulle hantera godtyckliga konverteringar - eller generera ett fel när konverteringen inte kunde stödjas. En anledning till detta system var att de olika internationella affiliatebolagen skulle rapportera sina data i sina lokalt lämpliga enheter, men HQ-systemet var tvungen att acceptera originaldata och ändå presentera den resulterande aggregerade datan i enheter som passade cheferna - där olika chefer var och en hade sin egen idé (baserat på deras nationella bakgrund och tjänstgöringstid i högkvarteret) om de bästa enheterna för sina rapporter.