多言語対応のデータベースモデリング

Question

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

私がそれを行う方法を考えるたびに疑問に思うのは、フィールドの複数の翻訳を解決する方法です。事例。

管理者がバックエンドから編集できる言語レベルの表には、基本、先進、流暢、熟語などの複数の項目があります。近い将来、おそらくもう1つの種類になります。管理者はバックエンドに行き、新しいレベルを追加して、それを適切な位置に並べ替えます。しかし最終的なユーザーのためにすべての翻訳をどのように扱いますか？

データベースの国際化に関するもう1つの問題は、ユーザー調査が米国と英国のDEと異なる可能性があるということです。各国ではレベルがあります（おそらく別のものになりますが最終的には違います） 。請求についてはどうですか？

これを大規模にモデル化する方法はありますか？

Answer 1

は、私はデータベースを設計するような方法である：

DB Designer Fork

によって

可視化任意のテーブルがちょうどに持つようにi18nテーブルのみ、PKが含まれていますフィールドを国際化するには、このPKを参照してください。テーブルtranslationは、この汎用IDと正しい翻訳リストとのリンクを担当します。

locale.id_localeはenとen_USISO syntaxesの両方を管理するVARCHAR(5)あります。

currency.id_currencyは、ISO 4217 syntaxを管理するCHAR(3)です。

pageとnewsletterの2つの例があります。これらの両方とも管理者が管理しますエンティティは、それぞれフィールドと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 

注：ここ

は、例えばクエリです。巨大なデータセットをお持ちの場合は、おそらくdenormalizing itを考えてクエリを最適化することができます。また、インデックスを使用してクエリのパフォーマンスを向上させることもできます（一部のDBでは、外部キーは自動的にインデックス付けされます（例：MySQL/InnoDB）。

Answer 2

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

• Designing database schema for a multi-language website
• What are best practices for multi-language database design?
• What's the best database structure to keep multilingual data?
• Schema for a multilanguage database
• How to use multilanguage database schema with ORM?

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

• Creating multilingual websites: Database Design
• Multilanguage database design approach
• Propel Gets I18n Behavior, And Why It Matters

が最善のアプローチは、多くの場合、すべての既存のテーブルのために、テキストアイテムを移動させるに新しいテーブルを作成しています。新しいテーブルのPKは、言語とともに古いテーブルのPKです。あなたのケースでは

：近くで... Matternの、事前、基本的な流暢：言語レベルについて

1. 表は、管理者がバックエンドから編集できること、のような複数のアイテムを持つことができます将来はおそらくもう1つのタイプになります。管理者はバックエンドに行き、新しいレベルを追加して、それを適切な位置に並べ替えます。しかし最終的なユーザーのためにすべての翻訳をどのように扱いますか？これは、2つのテーブルになり

    
   +----+-------+---------+ 
   | id | price | type | 
   +----+-------+---------+ 
   | 1 | 299 | basic | 
   | 2 | 299 | advance | 
   | 3 | 399 | fluent | 
   | 4 |  0 | mattern | 
   +----+-------+---------+ 
   

   ：

   は

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

2.  
   +----+-------+ +----+------+-------------+ 
   | id | price | | id | lang | type  | 
   +----+-------+ +----+------+-------------+ 
   | 1 | 299 | | 1 | en | basic  | 
   | 2 | 299 | | 2 | en | advance  | 
   | 3 | 399 | | 3 | en | fluent  | 
   | 4 |  0 | | 4 | en | mattern  | 
   +----+-------+ | 1 | fr | élémentaire | 
          | 2 | fr | avance  | 
          | 3 | fr | couramment | 
          : :  :    : 
          +----+------+-------------+ 
   

   を

   データベースのinternationalitzationを持つもう一つの問題は、おそらくユーザーのために研究は米国と英国のDEとは異なるかもしれません...各国で彼らはレベルを持っています（おそらくそれは別のものと同等ですが、fiナリー、異なる）。請求についてはどうですか？

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