2012-03-22 14 views
0

私は、ベースと派生測定単位の両方を使用する臨床アプリケーションを扱っています。測定単位の保存と管理

現在、ユニットを必要とする各テーブルの別々の列にテキストフィールドとして格納します。しかし、私はすべての測定単位を1つのテーブルに格納し、UOMを必要とするテーブルの外部キーを使用するようにデータベースを再設計する予定です。

この種の問題は、データベースレベルでの問題を解決します。しかし、Javaコードで、我々はそうのようなユニットを格納するための文字列を使用します。私は夜の馬は今後になる可能性のユニットを格納するための文字列を使用して想像

class Foo{ 
    double amount; 
    String unit; 
} 

。私は2つのFoosを比較したり、2つのFoosを同じユニットなどがあることを確認して追加することができるように、測定単位を管理するためのクリーンな方法についての提案が必要です。

+0

データベースの測定単位をマップするクラスを持たず、直接使用することはできませんか? –

+0

@ManuLetrollはデータベースヒットの価値があるのですか? – Woot4Moo

+0

まあ、そうではないかもしれませんが、それは最も論理的なものですIMO。 –

答えて

1

あなたは文字列よりも優れた抽象化を持つべきだと思います。それはプリミティブ以上のものではありません。

私はUnitsクラスを書いて、これらのStringをデータベースから解析して格納し、簡単に比較できるようにしたいと思います。

public class Units { 
    private final String name; 

    // constructors, equals, hashCode, toString and other operations here 
} 

単位のカテゴリを持つと便利な場合もあります。 (あなたは多くの方法で圧力を測定することができます)英国と国際単位は同じことを表すことができます。

enum Units { 
    Kilograms,Pounds,Stone 
} 

class Foo { 
    double amount; 
    Units units; 
} 

あなたはまた、物理量(例えば力、質量、電荷、時間など)別に

+0

これは、データベースレベルでシステムの一貫性を保つ方法を解決しません。それはおそらく不必要な抽象化でもあります。抽象度が高いほど複雑さが増し、複雑性が増えるほどトラブルやバグが多くなります。それがアメリカのユニットかイギリスのユニットかフランスのユニットかどうかを知ることが重要な魅力的なケースがない限り、それは価値があるよりも難しいでしょう。 – PlexQ

+0

私は同意しません。より良い抽象化は不要なトラブルではありません。あなたのUnits enumはどのように改善されていますか?科学者が知っているように、フランスとアメリカの単位はありませんが、メトリックとイギリス(例えば、kg対lbm)があります。あなたは列挙している圧力、時間、および他のすべてのタイプのユニットを持っていますか?それは私にとってもっと悪い考えです。 OPは明示的にコンバージョンについて尋ねました。あなたのenumはまったく助けません。 – duffymo

+0

申し訳ありませんが、間違っています。アメリカのガロンとイギリスのガロンは同じではありません。メトリックユニットは、パリで開催される一連の標準ユニットによって保持されるため、フランス語はいずれの場合も適切なモニカと思われます。 – PlexQ

0

私はJScience libraryを実装JSR 275です。あなたはクラス内Stringオブジェクトを使用して、本質的には何も問題はありません新しいライブラリを追加したくない場合は

UnitConverter toKilometers = MILE.getConverterTo(KILOMETER); 
double km = toKilometers.convert(Measure.valueOf(100, MILE).doubleValue(MILE)); 

this postによると、それは次のようなことを行うことができます。あなたがそれらについて計算を実行するつもりなら、心配することはあまりありません。しかし、おそらくDoubleを使用する必要があります。これは、メトリックシステムとの間で「正しい」翻訳を取得する方法になります。

+0

私は確かにJScienceを変換などと考えていますが、データベースに保存したすべてのUOM値をJScienceクラスにマップする必要もあります。私は新しいライブラリを持参する価値があるのか​​、それとも自家製のソリューションで問題を解決できるのか不思議です。 – user330973

+0

私は様々なJSRとユニットライブラリを終日見てきました。それらのどれも、シリアライゼーションには最適ではありません。本当にライブラリが必要です。 ユニットにenumを使用しないこれらのコードを何が作成したのか分かりませんが、正確に何が起こったのでしょうか。 –

0

変換の問題に基づいてカテゴリを持っているかもしれません、列挙型は、これを解決するために公正な方法ですほとんどのORMはenumをStringに変換します。あなたのJavaはタイプセーフであり、簡単なチェック制約を使用してデータベースの一貫性を保つことができます。ほとんどすべてのRDBMSがそれらをサポートしています。

もっと洗練されたものにする必要がある場合は、方法がありますが、しばしば複雑になると、必ずしもより良い問題ではありません。

+0

私の最初の選択はenumでもありましたが、将来、さらにユニットを追加してください。 – user330973

+0

もう一つの解決策は、完全性の改善ももたらさない。無効な文字列がメインの行に挿入されている可能性があるので、新しいランダムユニットをそのテーブルに挿入することができました。どちらの場合でも一貫性を保つためにはチェック制約が必要です。 – PlexQ

+0

データベースの整合性はスキーマ設計者の関心事です。また、スキーマがないと不正な単位を入力できなくなります。 – duffymo

関連する問題