Multilang目录（带自定义字段）数据库结构设计

Question

不久，我将开始编写将具有multilang内容支持的目录（php + mysql）。现在我正在考虑设计数据库结构的最佳方法。此刻，我看到multilang处理3种方式：

1）具有为每种语言的具体数据单独的表，即schematicly它会是这样的：

• 将有一个表Main_Content_Items，存储无法翻译的基本数据，如ID，creation_date，点击，投票等 - 它将只有一个，并将引用所有语言。

而这里是将被dublicated为每种语言表：

• Common_Data_LANG表（例如：common_data_en_us）（存储可被翻译，但存在对于共同/“静态”字段eny目录项：标题，desc等...）
• Extra_Fields_Data_LANG表（存储额外字段可以翻译的数据，但对于自定义项目组可能不同，即：id | item_id | field_type |值| ...） 然后在项目请求中，我们将根据用户/默认语言查看表格，并将 main_content表中的可转换数据加入。

优点：

• 我们可以更新“主”数据（即命中，票......）这是最经常更新，只有一个查询
• 我们不需要Ødublicate数据如果我们有4种或更多种语言，与只使用一个带'lang'字段的表格的结构相比，则为4倍或更多倍。因此MySQL查询将花费更少的时间去通过100000（例如）记录目录，而不是40万个或更多

缺点：

• +2表为每种语言

2）在内容表中使用'lang'字段：

• Main_Content_Items表（存储无法翻译的基本数据，如ID，creation_date，点击率，投票等...）
• Common_Data表（存储可翻译的常见/“静态”字段，但存在eny目录项目：| id | item_id | lang |标题| desc |等等......）
• Extra_Fields_Data表（存储额外字段的数据可以被翻译，但对于自定义项目组可能不同，例如：| id | item_id | lang | field_type | value | ... ） 因此，我们将根据'lang'字段将common_data和extra_fields加入到main_content_items中。

优点：

• 我们可以更新“主”数据（即命中，票......）这是最经常更新，只有一个查询
• 我们只有3个表内容数据

缺点：

• 我们custom_data和extra_fields桌上摆满机智所有语言H数据，所以它的X时间做大查询运行速度较慢

3）同为第2方式，但Main_Content_Items表合并Common_Data，有“郎”字段：

优点：

• ...？

缺点：

• 我们需要更新升级的“主”数据（即命中，票......）这是最经常更新，每种语言
• 我们custom_data和extra_fields表充满了所有语言的数据，所以它的X时间更长，查询运行速度更慢

很高兴听到有关“什么是更好的”和“为什么”的建议？或者有更好的方法吗？

在此先感谢...

Answer 1

我给了一个类似前面回答的this question，并强调这种技术的优点（这将是，例如，重要的是我让应用程序决定的语言和仅通过改变lang参数的SQL查询的WHERE子句中建立相应的查询。

GET操作的相当接近你的第二个解决方案。我没有完全得到了“extra_fields”但如果它是有道理的，你可以（！）将它合并到common_data表中。我会建议你反对第一个想法，因为w生病的桌子太多，而且很容易丢失那里的物品。

对你的编辑：我仍然认为第二种方法更好（这是我的optinion，所以它是相对的;））我不是专家优化，但我认为适当的索引和适当的表结构速度应该不是一个问题。与往常一样，最好的方式找到最有效的方法是做这两种方法，看看这是因为速度最好将数据结构各不相同，....