0

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

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.)

我真的很困惑这是最优化的方法。

4

2 回答 2

1

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

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

维基百科在这里有一篇关于数据规范化的好文章：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 - 外键）

如果您随后有搜索名称或描述的查询，则可以考虑根据需要在这些字段上添加更多键。

于 2013-10-31T15:07:28.947 回答
0

这是否是一个糟糕的实现取决于你想用它做什么。这看起来像是为项目、类型和语言的可变组合而设计的。唯一突出的是 item 列，因为您已经有了 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'

您将记录数量减半，并删除了一个搜索条件，抵消了添加的额外列。多个可选类型可能会使这个解决方案变得更糟，未知数量的类型会使它变得不可能。

于 2013-10-31T15:09:31.893 回答