mysql表结构建议？

Question

这个表对mysql有什么好处吗？我想让这种类型的数据存储在未来变得灵活。在这种表结构中，您不能使用主键，而可以使用索引...

我是否应该将表格的格式更改为具有标题-主键、宽度、长度、空格、耦合...

ID_NUM  Param   Value
1   Width   5e-081
1   Length  12
1   Space   5e-084
1   Coupling    1.511
1   Metal Layer     M3-0
2   Width   5e-082
2   Length  1.38e-061
2   Space   5e-081
2   Coupling    1.5
2   Metal Layer     M310

Answer 1

不，对于关系数据库，这是一个糟糕的设计。这是Entity-Attribute-Value设计的一个例子。它很灵活，但它打破了关系数据库的大部分规则。

在深入EAV设计作为灵活数据库的解决方案之前，请阅读这个故事：Bad CaRMa。

更具体地说，EAV的一些问题包括：

在不查询任何给定constraints.

• You的情况下，您无法知道任何给定VARCHAR.

• Particularly存在哪些属性。

• 您无法将任何属性设置为强制属性，等同于NOT NULL。

• 您不能使用数据库value不能使用MySQL数据类型；VARCHAR列必须是MySQL中的long VARCHAR，每个VARCHAR都存储在其自己的数据页上，因此这是非常浪费的。

当您使用EAV设计时，查询也非常复杂。Magento，一个开源的电子商务平台，广泛使用EAV，许多用户说，如果你需要自定义报告，它非常慢，很难查询。

要成为关系型属性，您应该将每个不同的属性存储在其自己的列中，并使用其自己的名称和适当的数据类型。

我已经在我的presentation Practical Object-Oriented Models in SQL和我的博客文章EAV FAIL以及我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming中写了更多关于EAV的内容。

Answer 2

您建议的内容称为

它有几个缺点，比如在执行引用完整性约束方面存在严重困难。此外，您必须提出的查询将比您的第二个建议使用规格化表(具有列的表：Primary Key, Width, Length, Space, Coupling, etc)要复杂一些。

因此，对于一个简单的项目，不要使用EAV模型。

如果您的计划是针对更复杂的项目，并且您希望获得最大的灵活性，那么也不要使用EAV。您应该研究一下，它在MySQL中更难实现，当然也不是一项容易的任务。但如果你成功了，你将拥有这两样东西:灵活性和最高级别的规范化(有些人称"EAV“为"6NF做错了”)。

Answer 3

根据我的经验，这种按行存储字段的想法需要非常仔细地考虑-尽管它似乎提供了许多优点，但它使许多常见的任务变得更加困难。

积极的一面是:它很容易扩展，而不需要更改数据库的结构，并且在某些方面抽象了数据存储的细节。

消极的一面:你需要查看所有按列存储的字段在DBMS中自动提供给你的所有日常事务:简单的内部/外部连接，一条语句插入/更新，唯一性，外键和其他数据库级约束检查，简单的搜索结果过滤和排序。

考虑一下您的体系结构中的一个查询，该查询返回y和z之间具有MetalLayer=X和宽度的所有项-按长度排序的结果。与使用列存储特定字段相比，该查询对您来说更难构造，对DBMS来说也更难执行。

总而言之，我唯一一次使用您建议的结构是在需要临时添加随机的非结构化附加数据的上下文中。在我看来，如果我不能使更传统的表结构工作，这将是最后的策略。