Wyprodukowałem podschemat bazy danych do obsługi jednostek eon temu (no dobrze, trochę przesadzam, ale to było jakieś 20 lat temu). Na szczęście miała do czynienia tylko z prostą masą, długością, wymiarami czasowymi - nie temperaturą, prądem elektrycznym, jasnością itp. Mniej prosta była walutowa strona gry - istniały niezliczone sposoby przeliczania jednej waluty i inny w zależności od daty, waluty i okresu, w którym obowiązywał kurs wymiany. To było obsługiwane oddzielnie od jednostek fizycznych.
Zasadniczo stworzyłem tabelę 'miary' z kolumną 'id', nazwą jednostki, skrótem i zestawem wykładników wymiaru - po jednym dla masy, długości, czasu. To jest wypełniane nazwami takimi jak „objętość” (długość =3, masa =0, czas =0), „gęstość” (długość =3, masa =-1, czas =0) - i tym podobne.
Była druga tabela jednostek, która identyfikowała miarę, a następnie rzeczywiste jednostki używane przez dany pomiar. Na przykład były beczki, metry sześcienne i wiele innych istotnych jednostek.
Była trzecia tabela, która określała współczynniki przeliczeniowe między poszczególnymi jednostkami. Składał się on z dwóch jednostek i multiplikatywnego współczynnika konwersji, który przeliczał jednostkę 1 na jednostkę 2. Największym problemem był tutaj dynamiczny zakres współczynników konwersji. Jeśli konwersja z U1 do U2 wynosi 1,234E+10, to odwrotność jest raczej małą liczbą (8,103727714749e-11).
Ciekawy jest komentarz S.Lotta o temperaturach - nie mieliśmy z nimi do czynienia. Procedura składowana rozwiązałaby to — chociaż zintegrowanie jednej procedury składowanej z systemem może być trudne.
Opisany przeze mnie schemat pozwalał na opisanie większości konwersji jednorazowo (w tym hipotetycznych jednostek, takich jak stadia na dwa tygodnie, lub mniej hipotetycznych, ale równie niejasnych – poza Stanami Zjednoczonymi – takich jak akr-stopy), a konwersje można było zweryfikować (na przykład oba jednostki w tabeli współczynników konwersji musiały mieć tę samą miarę). Można go rozszerzyć, aby obsłużyć większość innych jednostek - chociaż jednostki bezwymiarowe, takie jak kąty (lub kąty bryłowe), stwarzają kilka interesujących problemów. Istniał kod wspierający, który obsługiwałby dowolne konwersje - lub generował błąd, gdy konwersja nie mogła być obsługiwana. Jednym z powodów tego systemu było to, że różne międzynarodowe firmy stowarzyszone zgłaszały swoje dane w swoich lokalnie dogodnych jednostkach, ale system centrali musiał akceptować oryginalne dane, a mimo to prezentować wynikowe dane zagregowane w jednostkach, które odpowiadały menedżerom – gdzie każdy z nich był inny. mieli własny pomysł (w oparciu o pochodzenie narodowe i długość służby w kwaterze głównej) na temat najlepszych jednostek do swoich raportów.
