国際化を使用したMySQLデータベース設計

Question

私は中規模のアプリケーションで作業を開始するつもりです。私はそのデータベース設計を計画しています。 私が確信していないことの1つはこれです。 「タイトル、alternative_title、SHORT_DESCRIPTION、説明」

：のような一般的な国際化フィールドを、共有する「membership_options、gender_options、language_optionsなど」

これらの各テーブルを： 私のような国際化が必要になります多くのテーブルを、持っています

これを行う最善の方法はあなたの意見ですか？ 必要なテーブルごとに同じフィールドを持つi18nテーブルがありますか？

かのような何かを実行します。このようなものを繰り返す私を避けるだろう

Membership table  Gender table 
----------------  -------------- 
id | created_at  id | created_at 
1 - 22.03.2001  1 - 14.08.2002 
2 - 22.03.2001  2 - 14.08.2002 


General translation table 
------------------------- 
record_id | table_name | string_name | alternative_title| .... |id_language 
1  - membership regular   null      1 (english) 
1  - membership normale   null      2 (italian) 
1  - gender  man    null      1(english) 
1  -gender  uomo   null      2(italian) 

を：

membership_translation table 
----------------------------- 
membership_id | name | alternative_title | id_lang 
1    regular null    1 
1    normale null    2 

gender_translation table 
----------------------------- 
gender_id | name | alternative_title | id_lang 
1   man  null    1 
1   uomo null    2 

をというように、私はおそらく、DBテーブルの数を減らすだろうが、私はパフォーマンスについては不明です。私はDBデザイナーではないので、教えてください。

Answer 1

これが最も一般的な方法は、membershipとmembership_mlの2つのテーブルで、一方はローカライズされた文字列を格納するベース値とmlテーブルを格納しています。これは、2番目のオプションに似ています。このように見えるシステムのほとんどは、get_goから国際化を念頭に置いて設計されていなかったので、そうした方法で作られています。そのため、余分な_mlテーブルは後で「タック」されました。

もっと良い選択肢は、あなたの最初のオプションに似ていますが、少し異なります。すべての翻訳を格納する中央テーブルがありますが、そこにテーブル名とフィールド名を入れる代わりに、すべての翻訳を格納するためにトークンと中央の "Content"テーブルを使用します。そうすれば、必要に応じて、基本表のトークンとContent表の変換の間に何らかのRIを適用することができます。

実際はasked a questionですが、この後ほどのことですから、ここでスキーマの例を書き換えるのではなく、いくつかの情報を見ることができます。

Answer 2

私はまた、最良の解決策は、別のテーブルに翻訳を保持することだと思います。このアプローチでは、オープンソースのOpen Cartを使用して、問題を扱う方法を見てみることができます。他の情報源はここにあります。特に、「http://www.gsdesign.ro/blog/multilanguage-database-design-approach/」のコメントセクションにあります。