Question

我曾在一个项目中工作，其表格有点像这样：

tbl_texts
id, item_id, item, type, lang, value
1, 44, 'product', 'name', 'en', 'Product Name'
2, 44, 'product', 'description', 'en', 'Product description'
3, 55, 'category', 'name', 'en', 'Category name'
4, 55, 'category', 'name', 'fi', 'Category finnish name'

在6个字段中，1个是主键，4个是组合索引。从未使用主键选择数据。始终使用Item_id，item，type，lang索引。

1）我想知道这是存储数据的好方法还是坏方法？

2）设置一个必须连接两次的表是不好的设计（如果你想要产品的名称和描述）。

3）我应该将数据分成这样的表：

tbl_product_texts
id, product_id, type, lang, value

tbl_category_texts

(etc.)

4）或者像这样：

tbl_product_names
id, product_id, lang, name

tbl_product_descriptions
id, product_id, lang, description

(etc.)

5）或者甚至喜欢这样：

tbl_product_names_en
id, product_id, name

tbl_product_descriptions_en
id, product_id, description

(etc.)

我真的很困惑，这是最好的方法。

Answer 1

存储数据的“最佳”方式是一个非常开放的问题。在设计数据存储架构时，您需要考虑多个方面：

您的数据如何访问？（查询优化）
您的数据是如何创建的？
您的数据库架构将来发生变化的可能性有多大？

Wikipedia在这里有一篇关于数据规范化的好文章：http://en.wikipedia.org/wiki/Database_normalization

我个人会根据底层数据创建有意义的表。如果产品与类别足够不同，那么我会将它们存储在不同的表中。虽然您只提供了一小部分数据，但我假设每个产品都有多个名称和描述，但每种语言只有一个条目。有了这个，您将拥有以下内容：

Products:
  PK: id
  ...other columns that each product only has a single value for (price for example)

Product_Texts:
  PK,FK: product_id 
  PK:    language
         name
         description

（PK - 主键，FK - 外键）

如果您有查询名称或说明的查询，则可以考虑根据需要在这些字段上添加更多密钥。

Answer 2

这是否是一个糟糕的实现取决于你想用它做什么。这看起来像是为项目，类型和语言的可变组合而设计的。唯一突出的是项目列，由于您已经拥有item_id，因此可能不需要。

如果当前实现有效并且没有性能问题，则可能无需更改任何内容。毕竟，改善目前的状况需要时间，可能会更好地用于解决重要问题或建立新功能。

如果此设置导致问题，您将需要查看您的要求。例如，如果您知道每个项目始终存在固定数量的可能类型，则可能是一个解决方案（仅示例两种可能的类型）：

tbl_texts
id, item_id, item, lang, name_value, desc_value
1, 44, 'product', 'en', 'Product Name', 'Product description'
3, 55, 'category', 'en', 'Category name', 'Category description'
4, 55, 'category', 'fi', 'Category finnish name', 'Category finnish description'

您将记录数量减半，并删除了一个搜索标准，抵消了添加的额外列。多种可选类型可能会使这种解决方案变得更糟，未知数量的类型将使其无法实现。

在MySQL表中拆分数据的好处

2 个答案: