すぐに、多言語コンテンツをサポートするカタログ (php+mysql) に取り組む予定です。そして今、データベース構造を設計する最善の方法を検討しています。現時点では、multilang を処理するための 3 つの方法があります。
1）言語固有のデータごとに個別のテーブルを用意します。つまり、概略的には次のようになります。
- 1 つのテーブルMain_Content_Itemsがあり、ID、creation_date、ヒット数、投票などの翻訳できない基本データを格納します。これは 1 つだけで、すべての言語を参照します。
そして、ここに各言語用に複製されるテーブルがあります:
- Common_Data_LANG テーブル (例: common_data_en_us) (翻訳可能な共通/「静的」フィールドを保存しますが、eny カタログ アイテムに存在します: title、desc など...)
- Extra_Fields_Data_LANG テーブル(翻訳できる追加フィールド データを保存しますが、カスタム アイテム グループでは異なる可能性があります。つまり、次のようになります: | id | item_id | field_type | value | ...) 次に、アイテム リクエストで、user/ に従ってテーブルを調べます。デフォルトの言語を設定し、翻訳可能なデータをmain_contentテーブルと結合します。
長所：
- 最も頻繁に更新される「メイン」データ (つまり、ヒット数、投票数など) を 1 つのクエリだけで更新できます。
- 「lang」フィールドを持つ1つのテーブルのみを使用する構造と比較して、4つ以上の言語がある場合、データを4倍以上複製する必要はありません。したがって、MySql クエリは、400000 以上ではなく、100000 (たとえば) レコード カタログを通過するのにかかる時間が短くなります。
短所：
- 言語ごとに+2テーブル
2) コンテンツ テーブルで「lang」フィールドを使用する:
- Main_Content_Items テーブル(ID、作成日、ヒット数、投票数など、変換できない基本データを格納します...)
- Common_Data テーブル(翻訳可能な共通/「静的」フィールドを保存しますが、eny カタログ アイテムに存在します: | id | item_id | lang | title | desc | など...)
- Extra_Fields_Data テーブル(翻訳可能であるが、カスタム項目グループごとに異なる可能性がある追加フィールド データを保存します。つまり、| id | item_id | lang | field_type | value | ...) したがって、common_data と extra_fields を main_content_items に結合します。 「lang」フィールドに。
長所：
- 最も頻繁に更新される「メイン」データ (つまり、ヒット数、投票数など) を 1 つのクエリだけで更新できます。
- コンテンツデータ用のテーブルは 3 つだけです
短所：
- すべての言語のデータで満たされた custom_data および extra_fields テーブルがあるため、X 倍大きくなり、クエリの実行が遅くなります
3) 2 番目の方法と同じですが、「lang」フィールドを持つ Common_Data とマージされた Main_Content_Items テーブルを使用します。
長所：
- ...？
短所：
- すべての言語で最も頻繁に更新される更新「メイン」データ (つまり、ヒット数、投票など) を更新する必要があります。
- すべての言語のデータで満たされた custom_data および extra_fields テーブルがあるため、X 倍大きくなり、クエリの実行が遅くなります
「何が良いのか」「なぜ」についての提案を喜んで聞きますか? それとももっと良い方法がありますか？
前もって感謝します...