Question

我有一个存储客户有关产品的查询的数据库。

查询参考（文本），产品编号（int）和修订号（int）一起唯一标识销售和客户之间的单一讨论。

因此，对于单个查询的具体细节，每个表都有很多表，uqniuely由enq，pdt和rev值组合确定。

CREATE TABLE不对任何字段使用任何AUTO INCREMENT UNIQUE PRIMARY KEY。

我的问题是，这个数据库设计是否可以接受？表格是否应该规范化？

感谢您的建议。

Answer 1

拥有PRIMARY KEY（或UNIQUE约束）将首先确保这些值确实是唯一的，其次，将极大地改善对给定查询的搜索。

PRIMARY KEY意味着创建一个超过(enq, pdt, rev)的索引，以及此查询：

SELECT  *
FROM    enquiries
WHERE   enq = 'enquiry'
        AND pdt = 'product'
        AND rev = 'revision'

将在单一索引搜索中完成。

如果没有索引，此查询将需要扫描整个表格，并且无法保证您不会最终得到重复项。

除非是非常非常非常特殊的条件（如重度插入的日志表），否则表格上应始终有PRIMARY KEY。

Answer 2

不需要使用AUTOINCREMENT，但每个表都应该有一个PRIMARY KEY。主键可以是多个字段的组合，它们一起唯一地标识记录。

根据您告诉我们的内容，是的，设计是可以接受的，只要您明确声明查询引用（文本），产品编号（int）和修订号（int）的组合作为主键一起使用唯一标识一次讨论。

出于性能原因，人们有时会对数据库进行非规范化。如果select查询比插入和更新频繁得多，并且感兴趣的select查询因为必须加入的表的数量而返回的速度很慢，那么请考虑非规范化。

如果您提供的运行速度慢的特定查询，您将获得许多具体建议。

Answer 3

就个人而言，我总是在所有表格上都有某种主键，即使它是一个用于其他任何内容的自动加入号码

关于规范化，我认为应该争取规范化表格，但实际上，当表格设计良好但没有规范化时，有很多好的理由。这就是数据库设计的“理论”符合现实的地方 - 但是当你偏离规则时（而不是仅仅不了解规则或相反），了解规范化是什么，努力争取以及有充分理由是很好的。更糟糕的是忽视了良好的设计规则。）

Answer 4

这是两个问题。（1）不需要总是有自动增量键。但它很实用，因为您可以使用它来轻松处理数据。也没有必要的重复。（2）当你为学校做作业时，规范化是必须的，但如果事情变得艰难，你可以打破它，以便在不危及数据完整性的情况下让你的生活更轻松。

Answer 5

我正在从这个群体中分裂出来。不要将查询引用（文本），产品编号（int）和修订号（int）作为主键。您表示查询参考是文本类型，您是说它是25或50或500个字符宽？如果主键是从那些字段构成的，那么在我的视图中它将太宽，因为它将附加到为该表创建的每个索引，增加每个索引行的大小，增加三个字段的大小以及需要使用的任何表返回此表的外键也需要三个字段。

使这三个字段成为唯一索引。将自动增量值作为主键，并使其成为聚簇索引。将链接回此主表的表将在内存中占用较少的空间，以将表1中的数据链接到表2。

如果您的数据只有几千行甚至50,000或500,000，那么无论是标准化还是不标准化都无关紧要。当数据开始变得比可用的RAM缓存大时，那就是一个问题。

设计视图以将数据呈现给应用程序以实现业务规则。设计存储过程以接受要存储的数据。设计表结构以满足SLA中的响应时间。如果您必须规范化或非规范化或修改或索引或获得更大的服务器以满足SLA，应用程序永远不会知道，因为您始终通过符合业务规则的视图提供数据。

Answer 6

规范化理论中没有任何内容可以处理表格是否应该包含简单或复合主键。信不信由你，“主键”的概念不是数据关系模型的一个组成部分。

话虽如此，表几乎总是应该用主键定义。主键不必是单个列，也不需要通过自动增量填充。在您的情况下，它可以是三个唯一标识查询的列。

如果表没有声明的主键，则最终可能会出现重复的行。具有重复行的表表示一包元组，而不是一组元组。一旦处理行李而不是集合，关系模型预测的结果就不需要应用。这就是防止重复行非常重要的原因。

数据库：表是否应该规范化并具有主键？

6 个答案: