Ich habe vor einer Ewigkeit (okay, ich übertreibe leicht, aber es war vor etwa 20 Jahren) ein Datenbank-Unterschema für die Handhabung von Einheiten erstellt. Glücklicherweise musste es nur mit einfachen Massen-, Längen- und Zeitdimensionen zu tun haben – nicht mit Temperatur, elektrischem Strom oder Helligkeit usw. Etwas weniger einfach war die Währungsseite des Spiels – es gab unzählige verschiedene Möglichkeiten, zwischen einer Währung umzurechnen und eine andere abhängig von Datum, Währung und Zeitraum, für den der Umrechnungskurs gültig war. Das wurde getrennt von den physikalischen Einheiten gehandhabt.
Grundsätzlich habe ich eine Tabelle „Maße“ mit einer „ID“-Spalte, einem Namen für die Einheit, einer Abkürzung und einer Reihe von Dimensionsexponenten erstellt – jeweils einen für Masse, Länge, Zeit. Dies wird mit Namen wie „Volumen“ (Länge =3, Masse =0, Zeit =0), „Dichte“ (Länge =3, Masse =–1, Zeit =0) – und dergleichen gefüllt.
Es gab eine zweite Einheitentabelle, die ein Maß identifizierte, und dann die tatsächlichen Einheiten, die von einem bestimmten Maß verwendet wurden. Zum Beispiel gab es Barrel und Kubikmeter und alle möglichen anderen relevanten Einheiten.
Es gab eine dritte Tabelle, die Umrechnungsfaktoren zwischen bestimmten Einheiten definierte. Diese bestand aus zwei Einheiten und dem multiplikativen Umrechnungsfaktor, der Einheit 1 in Einheit 2 umwandelte. Das größte Problem hierbei war der dynamische Bereich der Umrechnungsfaktoren. Wenn die Umwandlung von U1 in U2 1,234E+10 ist, dann ist die Umkehrung eine ziemlich kleine Zahl (8,103727714749e-11).
Interessant ist der Kommentar von S.Lott zu den Temperaturen - damit mussten wir uns nicht befassen. Eine gespeicherte Prozedur hätte das angegangen - obwohl die Integration einer gespeicherten Prozedur in das System schwierig gewesen sein könnte.
Das von mir beschriebene Schema ermöglichte es, die meisten Umrechnungen einmal zu beschreiben (einschließlich hypothetischer Einheiten wie Furlongs pro zwei Wochen oder weniger hypothetischer, aber ebenso obskurer - außerhalb der USA - wie Acre-Feet), und die Umrechnungen konnten validiert werden (z. B. beides Einheiten in der Umrechnungsfaktortabelle mussten das gleiche Maß haben). Es könnte erweitert werden, um die meisten anderen Einheiten zu handhaben - obwohl die dimensionslosen Einheiten wie Winkel (oder Raumwinkel) einige interessante Probleme bereiten. Es gab unterstützenden Code, der willkürliche Konvertierungen verarbeitete - oder einen Fehler generierte, wenn die Konvertierung nicht unterstützt werden konnte. Ein Grund für dieses System war, dass die verschiedenen internationalen Tochterunternehmen ihre Daten in ihren lokal geeigneten Einheiten melden würden, das System der Zentrale jedoch die Originaldaten akzeptieren und die resultierenden aggregierten Daten dennoch in Einheiten präsentieren musste, die für die Manager geeignet waren – wobei jeder Manager unterschiedliche Manager war hatten ihre eigene Vorstellung (basierend auf ihrem nationalen Hintergrund und der Dienstzeit im Hauptquartier) über die besten Einheiten für ihre Berichte.
