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