47

多言語対応の Web アプリケーション用に大規模な DB モデルを作成する必要があります。

どのように行うかを考えるたびに私が疑問に思っていることの 1 つは、1 つのフィールドに対して複数の翻訳を行うことをどのように解決できるかということです。事例です。

管理者がバックエンドから編集できる言語レベルのテーブルには、基本、上級、流暢、重要などの複数の項目を含めることができます... 近い将来、おそらくもう 1 つのタイプになるでしょう。管理者がバックエンドに移動して新しいレベルを追加すると、正しい位置に並べ替えられます..しかし、最終ユーザーのすべての翻訳をどのように処理するのでしょうか?

データベースの国際化に伴うもう 1 つの問題は、おそらくユーザー調査では、米国、英国、DE で異なる可能性があることです...すべての国でレベルが異なります (おそらく別の国と同等ですが、最終的には異なります)。そして、課金はどうですか？

これを大規模にどのようにモデル化しますか?

4

2 に答える 2

70

データベースを設計する方法は次のとおりです。

データ・モデル

DB Designer Forkによる可視化

テーブルにはi18nPK のみが含まれているため、どのテーブルもこの PK を参照してフィールドを国際化する必要があります。テーブルtranslationは、この汎用 ID を正しい翻訳リストにリンクする役割を果たします。

locale.id_localeとISO 構文VARCHAR(5)の両方を管理するためのenです。en_US

currency.id_currencyISO 4217 構文CHAR(3)を管理するためのものです。

との 2 つの例がpageありnewsletterます。これらの管理者が管理するエンティティは両方とも、それぞれのフィールドを国際化する必要がありtitle/description、subject/content.

クエリの例を次に示します。

select
  t_subject.tx_translation as subject,
  t_content.tx_translation as content

from newsletter n

-- join for subject
inner join translation t_subject
  on t_subject.id_i18n = n.i18n_subject

-- join for content
inner join translation t_content
  on t_content.id_i18n = n.i18n_content

inner join locale l

  -- condition for subject
  on l.id_locale = t_subject.id_locale

  -- condition for content
  and l.id_locale = t_content.id_locale

-- locale condition
where l.id_locale = 'en_GB'

  -- other conditions
  and n.id_newsletter = 1

これは正規化されたデータ モデルであることに注意してください。巨大なデータセットがある場合は、非正規化してクエリを最適化することを考えることができます。クエリのパフォーマンスを向上させるためにインデックスを操作することもできます (一部の DB では、MySQL/InnoDBなどのように外部キーが自動的にインデックス化されます)。

于 2012-05-24T09:18:07.460 に答える
40

このトピックに関する以前の StackOverflow の質問:

役立つ外部リソース:

多くの場合、最善の方法は、すべての既存のテーブルに対して、テキスト項目を移動する新しいテーブルを作成することです。新しいテーブルの PK は、言語を含む古いテーブルの PK です。

あなたの場合：

  1. 管理者がバックエンドから編集できる言語レベルのテーブルには、基本、上級、流暢、重要などの複数の項目を含めることができます...近い将来、おそらくもう 1 つのタイプになるでしょう。管理者がバックエンドに移動して新しいレベルを追加すると、正しい位置に並べ替えられます..しかし、最終ユーザーのすべての翻訳をどのように処理するのでしょうか?

既存のテーブルはおそらく次のようになります。

+----+---------+---------+
| | ID | 価格 | タイプ |
+----+---------+---------+
| | 1 | 299 | 基本 |
| | 2 | 299 | 進む |
| | 3 | 399 | 流暢 |
| | 4 | 0 | 問題 |
+----+---------+---------+

次に、2 つのテーブルになります。

+----+-------+ +----+------+-------------+
| | ID | 価格 | | | ID | 言語 | タイプ |
+----+-------+ +----+------+-------------+
| | 1 | 299 | | | 1 | ja | 基本 |
| | 2 | 299 | | | 2 | ja | 進む |
| | 3 | 399 | | | 3 | ja | 流暢 |
| | 4 | 0 | | | 4 | ja | 問題 |
+----+---------+ | 1 | フランス | エレメンテール |
                 | | 2 | フランス | 前衛 |
                 | | 3 | フランス | 勇気 |
                 : : : :
                 +----+------+-------------+

  1. データベースの国際化に関するもう 1 つの問題は、おそらくユーザー調査では、米国、英国、DE で異なる可能性があることです...すべての国でレベルが異なります (おそらく別の国と同等ですが、最終的には異なります)。そして、課金はどうですか？

すべてのローカリゼーションは、同様のアプローチで行うことができます。テキスト フィールドを新しいテーブルに移動するだけでなく、ローカライズ可能なフィールドを移動することもできます。すべてのロケールに共通のフィールドのみが元のテーブルに残ります。

于 2012-05-24T08:50:33.673 に答える