很快我将开发具有多语言内容支持的目录（php + mysql）。现在我正在考虑设计数据库结构的最佳方法。目前，我看到了多种处理方式：
1）为每种语言特定数据设置单独的表格，即原理图如下所示：
- 将会有一个表 Main_Content_Items ，存储无法翻译的基本数据，如ID，creation_date，点击，投票等等 - 它将只有一个并且将引用所有语言。
以下是针对每种语言进行出版的表格：
- Common_Data_LANG表（例如：common_data_en_us）（存储可以翻译的公共/“静态”字段，但是对于eny目录项目存在：title，desc等等......）
- Extra_Fields_Data_LANG表（存储可以翻译的额外字段数据，但对于自定义项目组可以有所不同，例如：| id | item_id | field_type | value | ...）
然后在项目请求中，我们将根据用户/默认语言查看表格，并使用 main_content 表格加入可翻译数据。
优点：
- 我们可以更新仅使用一个查询更新的“主要”数据（即点击数，投票数...）
- 如果我们有4种或更多种语言与仅使用一个带有“lang”字段的表格的结构相比，我们不需要4次或更多次公开数据。因此，MySql查询将花费更少的时间来通过100000（例如）记录目录而不是400000或更多
缺点：
2）在内容表中使用“lang”字段：
- Main_Content_Items表（存储无法翻译的基本数据，如ID，creation_date，点击，投票等等......）
- Common_Data表（存储可以翻译的公共/“静态”字段，但是对于eny目录项存在：| id | item_id | lang | title | desc |等等... ）
- Extra_Fields_Data表（存储可以翻译的额外字段数据，但对于自定义项目组可以有所不同，例如：| id | item_id | lang | field_type | value | ...）
因此，我们将根据'lang'字段将common_data和extra_fields加入main_content_items。
优点：
- 我们可以更新仅使用一个查询更新的“主要”数据（即点击数，投票数...）
- 我们只有3个内容数据表
缺点：
- 我们有custom_data和extra_fields表填充了所有语言的数据，因此其X时间更长，查询运行速度更慢
3）与第二种方式相同，但Main_Content_Items表与Common_Data合并，具有'lang'字段：
优点：
缺点：
- 我们需要更新每个语言最常更新的更新“主要”数据（即点击数，投票数...）
- 我们有custom_data和extra_fields表填充了所有语言的数据，因此其X时间更长，查询运行速度更慢
很高兴听到关于“什么是更好”和“为什么”的建议？或者有更好的方法吗？
提前致谢...