4

さまざまな言語でメッセージを表示するために使用されている一連のプロパティ ファイルがあります。
したがって、現在の言語設定に応じて、メッセージは英語、フランス語、ドイツ語などで表示される可能性があります。
私のデータベースにはさまざまなレコードがあり、実際の値の代わりにプロパティ ファイルのキーを入力して、そのデータムは、対応する言語でメッセージを表示できます。
たとえば、次のようなレコードがデータベースにある可能性があります。

John| Smith| AQ| etc

対応するプロパティファイルのどこにorなどAQとして表示できますか。 私の問題は、データベース内の値がコードであるにもかかわらず、これらの属性で時折ソートする必要があるため、データベース内でソートできないことです。ここ から、一時テーブルと並べ替えを使用するよう提案されましたが、これは 1 つの属性に対しては問題ありません。 複数のプロパティ ファイルを処理し、可能であればコード内のチェックを回避するためのより一般的な解決策を探しています。 たとえば、これに対する一般的な 解決策はありますか?DoctorArzt



if this query sorts on X create this temp table

4

3 に答える 3

4

言語情報をプロパティ ファイルに保存するのではなく、データベースのテーブルに保存します。その後、それはすべて簡単に行うことができます。

Records:
first | last  | messageid |
John  | Smith | 1         |

Messages:
messageid | language | message |
1         | English  | Mr.     |
1         | Spanish  | Sr.     |
2         | English  | Doctor  |
etc...

次に、ローカル言語のメッセージでソートするクエリは次のようになります。

select first, last, message from records r
    inner join messages m on m.messageid = r.messageid
    where language = [your current language]
    order by message
于 2012-10-25T09:18:55.233 に答える
1

素晴らしい質問です。

私見ですが、この種の文字列をローカライズするために引き続きプロパティ ファイルを使用することをお勧めします。これにより、Java の組み込み IL8N 機能を使用できるようになり、時間を大幅に節約できます。

一般に、ドメイン オブジェクトのローカル文字列をデータベースに格納することをお勧めします。たとえば、製品データベースがあり、製品名を格納する必要がある場合、それは明らかにドメインの一部です。製品を管理する人は製品名も管理する必要があり、ビジネス ロジックと参照整合性を強制できるようにする必要があります。

これはあなたが与えた例に当てはまると主張することができます-タイトルは「人」ドメインの一部であり、データベースで管理する必要があります。

ユーザー インターフェイス要素 (ボタンのテキスト、メニュー項目の名前) については、プロパティ ファイルが完全に適切です。

「タイトル」がユーザー インターフェイスの一部であると考えている場合、またはローカライズ プロセスが確立されているために移動したくない場合は、SQL ではなく Java で並べ替えを行うことをお勧めします。データベースへの接続方法に応じて、それを行う方法はたくさんあります。

于 2012-10-25T09:44:11.440 に答える
0

アプリケーションの起動時に、キー、ロケール、および実際のメッセージを含むテーブルを同期できます。これらは通常のテーブルであるため、通常の SQL クエリでアクセスできます。

しかし、これは本当にアプリケーションロジックのように見えるので、常にアプリケーションで説明する並べ替えを行うことをお勧めします。

于 2012-10-25T09:15:56.357 に答える