我目前正在设计一个全新的数据库。在学校里，我们总是学会在每个表中放置一个主键。
我读了很多文章/讨论/新闻组帖子说最好使用唯一约束（也就是某些数据库的唯一索引）而不是 PK。
你的观点是什么？
vIceBerg
问问题
43485 次
16 回答
47
主键实际上只是一个不允许 NULL的候选键。因此，在 SQL 术语中 - 它与任何其他唯一键没有什么不同。
但是，对于我们的非理论 RDBMS，您应该有一个主键 - 我从未听说过它有其他争论。如果该 Primary Key 是surrogate key，那么您还应该对natural key(s)具有唯一约束。
要放弃的重要一点是，您应该对所有候选键（无论是自然键还是代理键）都有唯一的约束。然后，您应该选择最容易在外键中引用的一个作为您的主键*。
您还应该有一个聚集索引*. 这可能是您的主键，也可能是自然键 - 但也不是必须的。您应该根据表的查询使用情况选择聚集索引。如有疑问，主键是不错的首选。
尽管在技术上只需要引用外键关系中的唯一键，但普遍接受的标准做法是非常支持主键。事实上，如果某些 RDBMS 只允许主键引用，我不会感到惊讶。
编辑：有人指出，Oracle 的“聚集表”和“聚集索引”术语与 Sql Server 不同。我在 Oracle 语言中所说的等价物是索引有序表，建议用于 OLTP 表——我认为这将是 SO 问题的主要焦点。我假设如果您负责大型 OLAP 数据仓库，您应该已经对数据库设计和优化有自己的看法。
于 2008-10-01T16:55:53.180 回答
38
你能提供这些文章的参考吗？
我认为没有理由改变久经考验的方法。毕竟，主键是关系数据库的基本设计特征。
使用 UNIQUE 来实现相同的目的对我来说听起来很骇人听闻。他们的理由是什么？
编辑：我的注意力刚刚回到这个旧答案。也许您阅读的有关 PK 与 UNIQUE 的讨论涉及人们将某些东西作为 PK 来实现其唯一性的唯一目的。答案是，如果它是键，则将其设为键，否则将其设为 UNIQUE。
于 2008-10-01T16:15:25.630 回答
11
主键只是一个候选键（唯一约束），被挑选出来进行特殊处理（自动创建索引等）。
我希望反对他们的人认为没有理由将一把钥匙与另一把钥匙区别对待。这就是我的立场。
[编辑] 显然，即使没有 50 分，我也无法对自己的答案发表评论。
@chris：我不认为有任何伤害。“主键”实际上只是语法糖。我一直使用它们，但我当然不认为它们是必需的。需要唯一键，是的，但不一定是主键。
于 2008-10-01T16:19:01.490 回答
9
非常罕见的非规范化会让你想要一个没有主键的表。主键根据其作为 PK 的性质自动具有唯一约束。
当您想要保证添加到主键中的列的唯一性时，将使用唯一约束。
永远有一个PK的规则是一个很好的规则。
于 2008-10-01T16:16:59.230 回答
6
您应该始终拥有一个主键。
但是我怀疑您的问题只是措辞有点误导，您实际上是要询问主键是否应该始终是自动生成的数字（也称为代理键），或者是一些实际有意义的数据的唯一字段（也称为自然key)，比如人的 SSN，书籍的 ISBN 等等。
这个问题在 DB 领域是一场古老的宗教战争。
我的看法是，如果自然键确实是唯一的并且永远不会改变，那么自然键是更可取的。但是，您应该小心，即使是像个人 SSN 这样看似稳定的东西，在某些情况下也可能会发生变化。
于 2008-10-01T19:20:09.137 回答
4
除非该表是在您处理数据时暂存数据的临时表，否则您总是希望在表上放置一个主键，原因如下：
1 - 唯一约束可以允许空值，但主键绝不允许空值。如果您在具有空值的列上运行带有联接的查询，则会从结果数据集中消除这些行，因为 null 不等于 null。这就是即使是大公司也会犯会计错误并不得不重述利润的原因。他们的查询没有显示应该包含在总数中的某些行，因为在他们的唯一索引的某些列中有空值。应该使用主键。
2 - 唯一索引将自动放置在主键上，因此您不必创建一个。
3 - 大多数数据库引擎会自动在主键上放置一个聚集索引，使查询更快，因为行连续存储在数据块中。（这可以更改为将聚集索引放在不同的索引上，如果这样可以加快查询速度。）如果表没有聚集索引，则行将不会连续存储在数据块中，从而进行查询较慢，因为读/写头必须在整个磁盘上移动才能获取数据。
4 - 许多前端开发环境需要主键才能更新表或进行删除。
于 2008-10-01T18:20:04.223 回答
3
主键应在您将建立从该表到将引用该值的其他表的关系的情况下使用。但是，根据表的性质和您正在考虑应用唯一约束的数据，您可以将该特定字段用作自然主键，而不必建立代理键。当然，代理键与自然键是完全不同的讨论。:)
如果此表与其他表之间没有建立关系，则可以使用唯一键。例如，一个包含有效电子邮件地址列表的表格，在插入新用户记录或类似之前将与之进行比较。或者，当您在具有主键但也必须绝对唯一的表中具有值时，可以使用唯一键。例如，如果您有一个包含用户名的 users 表。您不希望将用户名用作主键，但它也必须是唯一的，才能用于登录目的。
于 2008-10-01T16:17:39.120 回答
2
我们需要在这里区分逻辑结构和物理结构，同样也需要区分理论和实践。
首先：从理论上讲，如果没有主键，就没有表。就是这么简单。所以，你的问题不是你的表是否应该有一个主键（当然应该），而是你如何在 RDBMS 中标记它。
在物理级别，大多数 RDBMS 将主键约束实现为唯一索引。如果您选择的 RDBMS 是其中之一，那么在将列指定为主键和简单地对列设置唯一约束之间可能没有太大的实际区别。但是：其中一个选项捕获了您的意图，而另一个则没有。所以，这个决定是不费吹灰之力的。
此外，如果正确标记了主键，则某些 RDBMS 会提供其他功能，例如图表和半自动外键约束支持。
任何告诉你使用唯一约束而不是主键作为一般规则的人都应该提供一个非常好的理由。
于 2008-10-01T18:51:05.163 回答
1
问题是主键可以是一个或多个唯一标识表的单个记录的列，其中唯一约束只是对字段的约束，它只允许表中任何给定数据元素的单个实例。
就个人而言，我使用 GUID 或自动递增的 BIGITS（SQL SERVER 的身份插入）作为用于在我的表之间进行交叉引用的唯一键。然后我将使用其他数据来允许用户选择特定的记录。
例如，我将有一个员工列表，并为我在幕后使用的每条记录附加一个 GUID，但是当用户选择员工时，他们会根据以下字段选择他们：LastName + FirstName + 员工编号。
在这种情况下，我的主键是 LastName + FirstName + EmployeeNumber，而唯一键是关联的 GUID。
于 2008-10-01T16:18:59.290 回答
1
帖子说最好使用唯一约束（也就是某些数据库的唯一索引）而不是 PK
我想这里唯一的一点是相同的旧讨论“自然与代理键”，因为唯一索引和 pk 是同一回事。
翻译：
帖子说最好使用自然键而不是代理键
于 2008-10-01T19:02:19.537 回答
1
我通常同时使用 PK 和 UNIQUE KEY。因为即使您没有在架构中表示 PK，也会在内部为您生成一个。SQL Server 2005 和 MySQL 5 都是如此。
但我不在我的 SQL 中使用 PK 列。它用于管理目的，例如删除一些错误的行，如果设置为 AUTO INCREMENT，则找出 PK 值之间的差距。而且，将 PK 作为数字而不是一组列或字符数组是有意义的。
于 2008-10-02T01:25:22.767 回答
1
我已经写了很多关于这个主题的文章：如果您阅读我的任何内容，请清楚我可能专门指的是 Jet aka MS Access。
在 Jet 中，这些表使用非维护聚集索引（在紧凑型上聚集）在 PRIMARY KEY 上进行物理排序。如果表没有 PK 但确实有在 NOT NULL 列上使用 UNIQUE 约束定义的候选键，那么引擎将为聚集索引选择一个（如果你的表没有聚集索引，那么它被称为堆，可以说根本不是表！）引擎如何选择候选键？它可以选择一个包含可为空的列吗？我真的不知道。关键是在 Jet 中，为引擎指定聚集索引的唯一显式方法是使用 PRIMARY KEY。当然，Jet 中的 PK 还有其他用途，例如，如果在 SQL DDL 中的 FOREIGN KEY 声明中省略了一个，它将用作键，但为什么不明确。
Jet 的问题在于大多数创建表的人不知道或不关心聚集索引。事实上，大多数用户（我打赌）在每张表上都放置了一个自动增量 Autonumber 列，并仅在该列上定义 PRIMARY KEY，而没有对自然键和候选键设置任何唯一约束（自动增量列是否实际上可以被视为不向最终用户公开的密钥本身就是另一个讨论）。我不会在这里详细介绍聚集索引，但可以说 IMO 唯一的自动增量列很少是理想的选择。
无论您使用什么 SQL 引擎，PRIMARY KEY 的选择都是任意的并且是特定于引擎的。通常，引擎会对 PK 赋予特殊含义，因此您应该找出它是什么并利用它来发挥自己的优势。我鼓励人们使用 NOT NULL UNIQUE 约束，希望他们会更多地考虑所有候选键，特别是当他们选择使用（应该）在数据模型中没有意义的“自动编号”列时。但我宁愿人们选择一个经过深思熟虑的键并使用 PRIMARY KEY，而不是出于习惯将其放在自动增量列上。
所有桌子都应该有PK吗？我说是的，因为否则至少意味着您错过了引擎提供 PK 的轻微优势，最坏的情况是您没有数据完整性。
顺便说一句，Chris OC 在这里对临时表提出了一个很好的观点，它需要顺序的主键（小写），而这不能通过简单的 PRIMARY KEY 约束（大写的 SQL 关键字）来实现。
于 2008-10-02T10:02:18.360 回答
1
首要的关键
1. Null 它不允许 Null 值。因此，我们引用 PRIMARY KEY = UNIQUE KEY + Not Null CONSTRAINT。 2. INDEX 默认情况下它添加一个聚集索引。 3. LIMIT 一张表只能有一个 PRIMARY KEY Column[s]。
唯一键
1. Null 允许 Null 值。但只有一个 Null 值。 2. INDEX 默认情况下，它添加一个 UNIQUE 非聚集索引。 3. LIMIT 一张表可以有多个UNIQUE Key Column[s]。
于 2015-06-24T10:05:43.273 回答
0
timestamp如果您计划使用 LINQ-to-SQL，则如果您计划执行更新，您的表将需要主键，如果您计划在断开连接的环境中工作（例如通过 WCF 服务应用程序传递对象），它们将需要列）。
如果您喜欢 .NET，PK 和 FK 就是您的朋友。
于 2008-10-01T16:26:54.310 回答
0
我认为你可能需要两者。主键本质上需要是唯一的并且不能为空。它们通常是代理键，因为整数比字符字段创建更快的连接，尤其是比多字段字符连接。但是，由于这些通常是自动生成的，因此它们不能保证数据记录的唯一性，不包括 id 本身。如果你的表有一个应该是唯一的自然键，你应该有一个唯一的索引来防止重复的数据输入。这是基本的数据完整性要求。
编辑补充：现实世界的数据通常没有真正保证规范化表结构中唯一性的自然键也是一个现实问题，特别是如果数据库是以人为中心的。姓名，甚至姓名、地址和电话号码的组合（想想父亲和儿子在同一个医疗机构）不一定是唯一的。
于 2008-10-01T20:53:05.090 回答
0
我自己也在想这个问题。如果你使用unique，你会伤害到2.NF。根据这一点，每个非 pk 属性都必须取决于 PK。此唯一约束中的属性对将被视为 PK 的一部分。
很抱歉 7 年后才回复这个问题，但不想开始新的讨论。
于 2015-02-19T09:51:37.387 回答