Ho prodotto un sottoschema di database per le unità di gestione un eone fa (va bene, esagero leggermente; erano circa 20 anni fa, però). Fortunatamente, aveva a che fare solo con semplici dimensioni di massa, lunghezza, tempo - non temperatura, corrente elettrica o luminosità, ecc. Piuttosto meno semplice era l'aspetto valutario del gioco:c'erano una miriade di modi diversi per convertire una valuta e un altro a seconda della data, della valuta e del periodo di validità del tasso di conversione. Questo è stato gestito separatamente dalle unità fisiche.
Fondamentalmente, ho creato una tabella "misure" con una colonna "id", un nome per l'unità, un'abbreviazione e un insieme di esponenti di dimensione, uno ciascuno per massa, lunghezza, tempo. Questo viene popolato con nomi come 'volume' (lunghezza =3, massa =0, tempo =0), 'densità' (lunghezza =3, massa =-1, tempo =0) - e simili.
C'era una seconda tabella di unità, che identificava una misura e quindi le unità effettive utilizzate da una particolare misura. Ad esempio, c'erano barili, metri cubi e ogni sorta di altre unità rilevanti.
C'era una terza tabella che definiva i fattori di conversione tra unità specifiche. Questo consisteva in due unità e il fattore di conversione moltiplicativo che converte l'unità 1 in unità 2. Il problema più grande qui era la gamma dinamica dei fattori di conversione. Se la conversione da U1 a U2 è 1.234E+10, l'inverso è un numero piuttosto piccolo (8.103727714749e-11).
Il commento di S.Lott sulle temperature è interessante:non abbiamo dovuto affrontarle. Una procedura memorizzata avrebbe risolto questo problema, sebbene l'integrazione di una procedura memorizzata nel sistema avrebbe potuto essere difficile.
Lo schema che ho descritto permetteva di descrivere la maggior parte delle conversioni una volta (comprese unità ipotetiche come furlongs per quindici giorni, o meno ipotetiche ma ugualmente oscure - al di fuori degli USA - come piedi acri), e le conversioni potevano essere convalidate (ad esempio, sia le unità nella tabella dei fattori di conversione dovevano avere la stessa misura). Potrebbe essere esteso per gestire la maggior parte delle altre unità, sebbene le unità adimensionali come gli angoli (o gli angoli solidi) presentino alcuni problemi interessanti. C'era un codice di supporto che gestiva conversioni arbitrarie o generava un errore quando la conversione non poteva essere supportata. Uno dei motivi di questo sistema era che le varie società affiliate internazionali avrebbero riportato i propri dati nelle loro unità convenienti a livello locale, ma il sistema HQ doveva accettare i dati originali e tuttavia presentare i dati aggregati risultanti in unità adatte ai gestori, dove diversi gestori ciascuno avevano una propria idea (basata sul loro background nazionale e sulla durata del servizio nel quartier generale) sulle migliori unità per i loro rapporti.
