質問: 多言語データベースのスキーマ 多言語ソフトウェアを開発しています。アプリケーションコードに関する限り、ローカライズ可能性は問題ではありません。言語固有のリソースを使用し、それらに適したあらゆる種類のツールを使用できます。しかし、多言語データベーススキーマを定義する最良の方法は何ですか?多数のテーブル(100以上)があり、各テーブルにローカライズ可能な複数の列を含めることができるとします(nvarchar列のほとんどはローカライズ可能です)。たとえば、テーブルの1つに製品情報が含まれている場合があります。create table t_product ( name nvarchar(50), description ntext, price number(18, 2) ) name列とdescription列で多言語テキストをサポートするための3つのアプローチを考えることができます。 言語ごとに個別の列 システムに新しい言語を追加する場合、次のように翻訳されたテキストを保存するために追加の列を作成する必要があります。 create table t_product ( name_en nvarchar(50), name_de nvarchar(50), name_sp nvarchar(50), description_en ntext, description_de ntext, description_sp ntext, price number(18,2) ) 各言語の列を含む翻訳テーブル 翻訳されたテキストを保存する代わりに、翻訳テーブルへの外部キーのみが保存されます。 translationsテーブルには、各言語の列が含まれています。 create table t_product ( name_fk int, description_fk int, price number(18, 2) ) create table t_translation ( translation_id, text_en ntext, text_de ntext, text_sp ntext ) 各言語の行を含む翻訳テーブル 翻訳されたテキストを保存する代わりに、翻訳テーブルへの外部キーのみが保存されます。 translationsテーブルにはキーのみが含まれ、個別のテーブルには言語への翻訳ごとの行が含まれます。 create table t_product ( name_fk int, description_fk int, price number(18, 2) ) create table t_translation ( translation_id ) create table t_translation_entry ( translation_fk, language_fk, translated_text ntext ) create table t_translation_language ( language_id, language_code char(2) ) 各ソリューションには長所と短所がありますが、これらのアプローチの経験、推奨するもの、多言語データベーススキーマの設計方法について知りたいと思います。
回答: 3番目のオプションは、いくつかの理由により最適です。 新しい言語のデータベーススキーマを変更する必要はありません(したがって、コードの変更を制限します) 未実装の言語や特定のアイテムの翻訳のために多くのスペースを必要としません 最も柔軟性が高い スパーステーブルにならない nullキーを心配する必要はなく、nullエントリの代わりに既存の翻訳を表示していることを確認する必要はありません。 データベースを変更または拡張して、他の翻訳可能なアイテム/もの/などを含める場合、同じテーブルとシステムを使用できます。これは、他のデータからは非常に切り離されています。 -アダム