这张table对mysql有用吗?我想在未来为这种类型的数据存储提供灵活性。使用此表结构,您不能使用PRIMARY KEY,而只能使用索引。。。
我是否应该将表格的格式更改为具有标题-主键、宽度、长度、间距、耦合。。。
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
5条答案
按热度按时间gev0vcfq1#
不,这是一个糟糕的关系数据库设计。这是Entity-Attribute-Value设计的一个示例。它很灵活,但它打破了关系数据库的大部分规则。
在您深入研究EAV设计作为灵活数据库的解决方案之前,请阅读以下故事:Bad CaRMa。
更具体地说,EAV的一些问题包括:
value
列必须是长VARCHAR。使用EAV设计时,查询也非常复杂。Magento是一个开源电子商务平台,广泛使用EAV,许多用户表示,如果你需要定制报告,它会非常慢,很难查询。
为了保持关系,您应该将每个不同的属性存储在自己的列中,并使用自己的名称和适当的数据类型。
我在我的演讲Practical Object-Oriented Models in SQL和博客EAV FAIL以及我的书SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming中写了更多关于EAV的内容。
ljo96ir52#
你的建议叫做**
EAV model (Entity–Attribute–Value)
**它有几个缺点,比如在强制引用完整性约束方面存在严重困难。此外,与第二个建议(列表:
Primary Key, Width, Length, Space, Coupling, etc
)的标准化表相比,您必须提出的查询要复杂一些。因此,对于一个简单的项目,不要使用EAV模型。
如果您的计划是针对更复杂的项目,并且您希望获得最大的灵活性,那么也不要使用EAV。您应该看看**
6NF (6th Normal Form)
**,它更难实现,在MySQL中当然不是一件容易的任务。但是,如果你成功了,你将拥有两种好处:灵活性和最高级别的标准化(有些人称“EAV”为“6NF做得不对”)。j2cgzkjk3#
根据我的经验,这种按行存储字段的想法需要非常仔细地考虑——尽管它似乎有很多优点,但它使许多常见任务变得更加困难。
积极的一面是:它易于扩展,不需要更改数据库的结构,并且在某种程度上抽象了数据存储的细节。
负面方面:您需要查看DBMS中按列自动存储字段的所有日常内容:简单的内部/外部连接、一条语句插入/更新、唯一性、外键和其他数据库级约束检查、搜索结果的简单筛选和排序。
考虑在您的体系结构中使用一个查询来返回MetalLayer=X且宽度介于y和z之间的所有项-结果按长度按耦合排序。与使用列存储特定字段相比,此查询的构造难度更大,DBMS的执行难度更大。
总而言之,我唯一一次使用你建议的结构是在需要临时添加随机非结构化附加数据的情况下。在我看来,如果无法使更传统的表结构工作,这将是最后的策略。
dsekswqp4#
这里需要考虑的几件事:
没有单个主键。这可以通过使主键由两列组成来克服(如Carl T的第二个示例)
Param列是重复的,为了规范化,您应该查看MGA的示例。
第三,“金属层”列是一个字符串,而不是像其他列一样的浮点值。
所以最好使用这样的表定义:
ma8fv8wu5#
当创建一个专门用于将来使用的表时,您必须问的主要问题是如何检索这些数据以及它的用途。就个人而言,我总是有一个唯一的标识符,通常是表的ID。
查看您的列表似乎没有任何唯一定义条目的内容,因此您将无法跟踪重复条目,也无法唯一检索记录。
如果你想保留这个设计,你可以创建一个由名称和参数值组成的复合主键。
这些创建表的例子表达了上面提到的两个选项。