1

私たちは旅行ポータルに取り組んでおり、旅行ポータルのコンテンツと詳細は心臓部です.複数のロケールでそれを計画しているため、各ロケールの動的データを処理する必要があります.

現在、次の表があります

Destination
Transport
Places of Interests
user comments etc.

各テーブルには、次のような多くのフィールドが含まれています

Name
ShortDescription
LongDescription

および多くのデータを含むことができる他の多くのフィールドがあり、ロケール固有の方法でデータを処理する必要があります。

このケースを処理するためのアプリケーションをどのように設計するのが最善かはわかりません.1つ思い浮かんだのは、各テーブルの各ロケールに追加の列を配置することですが、新しいロケールでは、データベースからコードレベルに変更する必要があることを意味します.そして、それはまったく良くありません。

各テーブルには、国際化に適したデータを含めることができる多くの列が含まれているため、私の質問は、このケースを処理する最良の方法は何かということです

edit1 いくつかの分析とゴーグリングを行った後、私の頭に浮かんだ1つのアプローチは以下のとおりです..

宛先のようにテーブルごとに変換テーブルを作成する予定です。次の設計があります。

    table languages
    -- uuid (varchar)
    -- language_id(varchar)
    -- name (varchar)  

    table Destination
    --uuid (varchar)
     other fields which are not part of internationalization.

table Destination_translation
-- id (int)
-- destination_id (int)
-- language_id (int)
-- name (text)
-- description(text)

上記のアプローチに対する貴重な提案は大歓迎です...

4

2 に答える 2

1

以前にアプリケーションを国際化したとき、ロケールベースの値のテーブルがありました。そこで、次のようにしました。

string_code、locale_code、値で構成される local_strings というテーブルを作成します。これには、さまざまな値の翻訳が含まれています。したがって、3 つの言語に翻訳した場合、string_code ごとに異なる locale_codes を持つ 3 つのエントリが存在することになります。

次に、各マスター テーブル (あなたの場合は宛先、トランスポートなど) には、local_strings テーブル内の string_code への参照があります。

最後に、データベースから値をクエリするときは、常に local_strings テーブルに参加し、常にユーザーの現在のロケールを使用するようにしてください。または、これらの値をメモリにキャッシュして、常にこのテーブルと結合しないようにすることもできます。ただし、私の経験では、テーブルがそれほど大きくなることはないため、テーブルに参加するだけのオーバーヘッドはあまりありません。

于 2011-04-03T06:47:33.003 に答える
0

これを解決するには、いくつかのオプションがあります。

  1. テーブルをロケール列で拡張し、すべてのクエリにロケールを含めます。ロケール列を含めるようにインデックスを変更することもできます。
  2. ローカライズされた文字列用に別のテーブルを作成する

テーブルが本物のように見え、データを直接見ることでテーブルを読み取ることができるため、私は間違いなくオプション 1 を好みます。また、副選択や結合を行う必要がなくなるため、パフォーマンスが向上します。オプション 2 の利点は、管理インターフェース (ある場合) のプログラマーにとってより簡単になることだけです。

于 2011-04-03T06:47:59.763 に答える