web-dev-qa-db-ja.com

国際的および多言語の目的のためのデータベースモデリング

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

方法を考えるたびに疑問を抱く1つの疑問は、フィールドの複数の翻訳を解決する方法です。事例。

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

データベースの国際化に関するもう1つの問題は、おそらくユーザー調査の場合、米国から英国、ドイツへと異なる可能性があるということです...すべての国でレベルがあります（それはおそらく他の国と同等ですが、最終的には異なります）。そして、請求はどうですか？

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

mysqldatabasedatabase-designinternationalizationmultilingual
38
udexter

これが私がデータベースを設計する方法です：

Data model

DB Designer Forkによる視覚化

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

_locale.id_locale_は、enと_en_US_ ISO構文 の両方を管理するVARCHAR(5)です。

_currency.id_currency_は ISO 4217構文 を管理するCHAR(3)です。

pageとnewsletterの2つの例があります。これら両方のadmin-managedエンティティは、それぞれのフィールド（_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 ））。

58
sp00m

このトピックに関するいくつかの以前のStackOverflow質問：

いくつかの有用な外部リソース：

多くの場合、最善の方法は、既存のすべてのテーブルについて、テキストアイテムの移動先となる新しいテーブルを作成することです。新しいテーブルのPKは、言語とともに古いテーブルのPKです。

あなたの場合：

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

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

     + ---- + ------- + --------- + 
 | id |価格|タイプ| 
 + ---- + ------- + --------- + 
 | 1 | 299 |基本| 
 | 2 | 299 |前進| 
 | 3 | 399 |流暢| 
 | 4 | 0 |重要| 
 + ---- + ------- + --------- +

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

     + ---- + ------- + + ---- + ------ + ------------- + 
 | id |価格| | id | lang |タイプ| 
 + ---- + ------- + + ---- + ------ + ------------- + 
 | 1 | 299 | | 1 | ja |基本| 
 | 2 | 299 | | 2 | ja |前進| 
 | 3 | 399 | | 3 | ja |流暢| 
 | 4 | 0 | | 4 | ja |問題| 
 + ---- + ------- + | 1 | fr | élémentaire| 
 | 2 | fr | avance | 
 | 3 | fr |クーラムメント| 
：：：:: 
 + ---- + ------ + ------------- +

  2. データベースの国際化に伴うもう1つの問題は、おそらくユーザー調査の場合、米国から英国、ドイツへと異なる可能性があるということです...すべての国でレベルがあります（多分それは別のものと同等ですが、最終的には異なります）。そして、請求はどうですか？

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

33
eggyal