問題の説明は少し曖昧で、アプリケーションの範囲はわかりませんが、システムアーキテクチャの観点から、MVCフレームワークを使用している場合は、すべてのデータベースユニットを保持することをお勧めします。同じで、UnitConversionコントローラーを作成します。このコントローラーは、標準の単位を入力として受け取り、必要な単位に基づいて値を出力します。ログインの間にこの情報が失われないように、データベース内のユーザー/クライアントレコードにフラグが保持され、ユーザーがどのユニットを好むかを通知します。標準の単位形式（たとえば、メートル）の値と目的の単位のフラグ（たとえば、「フィート」）をコントローラーに渡し、変換を実行して値を返します。
例外とメンテナンスを管理しようとするあらゆる種類のコードを記述してしまう可能性があるため、データベースに異なる単位タイプを保持しようとはしません（たとえば、クライアントが単位を変更したときにすべての値を更新します）。データベースに標準の単位を保持し、Robertが言及したZendFrameworkと同様のphpクラスを介して変換を行います。 「phpユニット変換」をグーグルで検索すると、ニーズに合ったクラスがいくつか表示されます。
更新時：
問題全体が表示されているかどうかはまだわかりませんが、理解できる限り最善の回答を心がけます。以前と同様に、データベースに1単位系、たとえばメトリックを保持するのが最善です。 user_prefのmeasurement_typeは、クライアントが何を望んでいるかを示します。たとえば、「IMPERIAL」です。データベースの分散度に応じて、値を保持する2つのソリューションのいずれかを選択できます。
-
DB内のアイテムには、重量、高さ、体積など、さまざまなプロパティ（列）がある場合があります。
-
アイテムを保持するアイテムテーブルがある場合があります。次に、プロパティを保持するプロパティテーブルがあります。プロパティテーブルには、property_id（主キー）、property（HEIGHT、WIDTH、LENGTH、WEIGHT）、property_type（SIZE、MASS、VOLUME、AWESOMENESS）、およびvalueの4つの列があります。次に、item_id、property_idの2つの列を持つProperty_Lookupテーブルがあり、これら3つのテーブルを結合すると、Itemに属する各プロパティのすべての値とユニットタイプが得られます。このスキーマでは、「値」列のすべてのエントリを単一の単位系（この例ではメトリック）に保持します。多対多の関係の詳細については、このリンクを参照してください（ http： //www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php 。
モデルはデータを取得し、これらのプロパティをUnit {system（METRIC *、IMPERIAL、BOTH）;にカプセル化します。 type（SIZE、MASS、VOLUME）;値}ミニモデル。それをコントローラーに渡します。レンダリング時に、ビューはクライアントが必要とするものに基づいて単位値を期待するため、コントローラーがビューのデータをまとめるときに、UnitConversionライブラリを介してUnitオブジェクトを送信します。 UnitConversionライブラリは、クライアントの優先システムのユーザーモデルと、ユニットモデルの「システム」をチェックし、必要な変換を行います（ライブラリは、データベースから取得したときにユニットモデルのシステムがメトリックであると想定できるため、これを行います。少し簡単にステップします）。次に、正しい単位（両方が選択されている場合は単位）で数値が出力され、ビューに渡すことができます。
上記の簡単な言葉は、システムアーキテクチャを扱う場合、問題に対する「正しい」解決策は常にないということです。これは、与えられた情報に基づいて物事を整理する方法ですが、作業内容に完全に適合するようにするには、おそらくかなり調整する必要があります。そうは言っても、私はあなたのシステムで機能するように上記を微調整し、上記を機能させるためにあなたのシステムを微調整するのではありません！これがあなたにいくつかの良いアイデアを与えることを願っています。