ユニットを処理するためのデータベースサブスキーマを1年前に作成しました（大丈夫、少し誇張していますが、約20年前です）。幸いなことに、温度、電流、光度などではなく、単純な質量、長さ、時間の次元のみを処理する必要がありました。ゲームの通貨側はそれほど単純ではありませんでした。1つの通貨間で変換する方法は無数にありました。もう1つは、コンバージョン率が有効だった日付、通貨、期間によって異なります。これは、物理ユニットとは別に処理されました。
基本的に、「id」列、単位の名前、略語、および一連のディメンション指数（質量、長さ、時間にそれぞれ1つずつ）を含むテーブル「measures」を作成しました。これには、「体積」（長さ=3、質量=0、時間=0）、「密度」（長さ=3、質量=-1、時間=0）などの名前が入力されます。
単位の2番目のテーブルがあり、メジャーを識別してから、特定のメジャーで使用される実際の単位を識別しました。たとえば、樽、立方メートル、その他のあらゆる種類の関連単位がありました。
特定の単位間の換算係数を定義する3番目の表がありました。これは、2つの単位と、単位1を単位2に変換する乗法変換係数で構成されていました。ここでの最大の問題は、変換係数のダイナミックレンジでした。 U1からU2への変換が1.234E+10の場合、その逆数はかなり小さい数値（8.103727714749e-11）です。
温度についてのS.Lottからのコメントは興味深いです-私たちはそれらに対処する必要はありませんでした。ストアドプロシージャはそれに対処していましたが、1つのストアドプロシージャをシステムに統合するのは難しいかもしれません。
私が説明したスキームでは、ほとんどの変換を1回記述でき（2週間あたりのハロンなどの仮想単位、または仮想的ではないが同様にあいまいな単位（米国外ではエーカーフィートなど）を含む）、変換を検証できます（たとえば、両方換算係数テーブルの単位は同じ測定値である必要がありました）。他のほとんどの単位を処理するように拡張できますが、角度（または立体角）などの無次元の単位にはいくつかの興味深い問題があります。任意の変換を処理するサポートコードがありました-または、変換がサポートされなかったときにエラーを生成します。このシステムの理由の1つは、さまざまな国際的な関連会社が現地の便利な単位でデータを報告することでしたが、本社システムは元のデータを受け入れ、結果として得られた集計データを管理者に適した単位で提示する必要がありました。レポートに最適なユニットについて、（国の背景と本社での任務の長さに基づいて）独自のアイデアを持っていました。