10

次の問題がより良い/異なる/共通の解決策を持っているかどうか、意見を求めています:

英語 (このアプリケーションのデフォルト言語) の製品名を含む製品データベースがあり、可能であれば名前の翻訳が必要です。

現在、私はこのセットアップを持っています:

製品表

CREATE TABLE products
(
  id serial NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_pkey PRIMARY KEY (id)
)

および製品ローカリゼーション テーブル

CREATE TABLE products_l10n
(
  product_id serial NOT NULL,
  "language" character(2) NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_l10n_pkey PRIMARY KEY (product_id, language),
  CONSTRAINT products_l10n_product_id_fkey FOREIGN KEY (product_id)
      REFERENCES products (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
)

次のクエリを使用して、ローカライズされた製品 (この場合はドイツ語) のリストを取得し、デフォルトの英語名にフォールバックします。

SELECT p.id, COALESCE(pl.name, p.name) 
from products p LEFT 
JOIN products_l10n pl ON p.id = pl.product_id AND language = 'de';

SQL コードは postgres の方言です。データは UTF-8 として保存されます。

4

6 に答える 6

7

は、私にはよく見えますよ。私が変更する可能性のある 1 つのことは、言語の処理方法です。おそらく、別のテーブルにする必要があります。したがって、次のようになります。

CREATE TABLE products_l10n
(
  product_id serial NOT NULL,
  language_id int NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_l10n_pkey PRIMARY KEY (product_id, language),
  CONSTRAINT products_l10n_product_id_fkey FOREIGN KEY (product_id)
      REFERENCES products (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
  CONSTRAINT products_l10n_language_id_fkey FOREIGN KEY (language_id)
      REFERENCES languages (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
)

CREATE TABLE languages
)
  id serial not null
  "language" character(2) NOT NULL
)

それに加えて、可能な限り最高のソリューションをお持ちだと思います。

于 2008-10-10T00:28:51.497 に答える
1

私が提供できる唯一のバリエーションは、国/方言の可能性も含めることができるということです。たとえば、英語 (en) ではなく、英語の US (en-US) を使用します。そうすれば、バリエーションをすべて考慮することができます (たとえば、英国のスペル、フランス系カナダ人はおそらくフランスで話されているフランス語とは異なる、など)。

于 2008-10-10T00:57:49.707 に答える
1

良さそうです - 私の好みのローカリゼーション手法に似ています - ワイド文字 (日本語) はどうですか? これを処理するために常に nvarchar を使用しました。

しかし、実際に私たちが国際的な購買業務で見つけたのは、各国のサプライヤーが異なるため、製品の国境を越えた一貫性がないということでした。そのため、インターフェイスを国際化/ローカライズしましたが、データベースは完全に異なっていました。

于 2008-10-10T00:34:38.427 に答える
0

この種のことを扱うとき、私は名前をまったく含まない product テーブルと、名前だけを保持する product_translation テーブルを構築するために使用します (もちろん、それ以上のことも)。

次に、この種のクエリになります。

選択する
    i.id、
    i.価格、
    it.label
から
    項目 i
    LEFT JOIN items_trans it
        ON i.id=it.item_id AND it.lang_id=(
            言語 ID を選択
            FROM items_trans
            WHERE item_id=i.id
            オーダーバイ
                (lang_id=1) DESC、
                (lang_id=0) DESC
            リミット 1
        )

どう思いますか ？

于 2010-02-04T07:55:16.570 に答える
0

他の人が言及していない唯一の複雑な要因はコード セットです。ヘブライ語、アラビア語、ロシア語、中国語、日本語を処理できますか? すべてが Unicode の場合、Unicode のスーパーセット (IIUC) である GB18030 (中国語) だけを気にする必要があります。

于 2008-10-10T21:40:46.470 に答える
0

私にはまともに見えます。

明らかに、ローカライズされた名前を Unicode 列に入れる必要があります。英語のデフォルトを ASCII フィールドに入れることを選択できます (データベースがそれをサポートしていると仮定します)。全体を通して Unicode を実行し、それを "忘れる" のが最善かもしれません。

于 2008-10-10T00:33:55.387 に答える