当我可以在组合列上使用具有唯一约束的单一主键时，为什么要使用复合主键？
在这种情况下，我正在考虑将表模式从单个主键更改为复合主键。
此更改将影响我的许多表和为查询此类表而编写的SQL语句(特别是联接查询)。
在对复合密钥方法的好处进行了一些研究之后，我发现了一个主要的卖点是它用于强制组合列的唯一性。
但是，我仍然可以保留我的单个主键表，然后添加一个唯一的约束来在如下的复合列上强制执行唯一性：
create table ... (
id primary key not null,
column1 ...
column2 ...
.
.
columnN ...
unique(column1, column2) // added this line to my existing tables
)现在来回答以下问题：
这两种方法的好处是什么？
显式定义复合主键或使用具有组合列上唯一约束的单个主键。为什么？
回答 2
Stack Overflow用户
发布于 2021-09-17 16:23:12
您不需要主键来执行唯一性。您可以使用unique约束或索引。
我不喜欢复合主键。以下是一些原因：
- 所有外键引用都必须以正确的顺序和匹配类型包含所有键。这使得定义这些表有点麻烦。
- 因为复合键包含在所有引用表中，所以这些表通常更大，从而导致性能下降。
- 如果您决定要将其中一个组件键的类型--例如字符串或
int的长度更改为numeric--您必须修改很多很多表。 - 在连接表时，必须包括所有的键。如果你错过了一个。。。嗯，代码在语法上是正确的，但是结果是错误的。
在某些情况下，复合键是可以接受的，例如没有外键引用的表。即使在这种情况下，我也使用合成键，但我完全理解另一种观点。
Stack Overflow用户
发布于 2021-09-18 07:55:44
我将从“其他观点”提到过的戈登林诺夫。
一般来说，我是“亲”合成键。
我认为合成键是一种通常被过度使用的优化技术，有时它只是因为程序员习惯了而导致了一种没有任何优点的悲观。
过度使用合成键的示例
- 在
int(4字节)和date(4字节)字段上有一个具有唯一约束的表 - 它们从未改变过
- 但是无论如何，有人添加了一个带有随机值的
uuid(16字节)字段 - 并在上面定义一个PK
让我们分析一下：
- Arithmetics：在每一行上增加16个字节+索引成本不是优化，而是一种悲观
- 代码：我不认为添加一个
AND会有什么影响 - 语义：自然密钥具有一定的业务价值，合成密钥不是
不要以为这只是一个假想的反例子，只是为了争论--我看到了很多这样的合成键。
备注：
答:在某些情况下，uuid 键可能是正确的，我在https://stackoverflow.com/a/69213338/1168212中描述了它们
B.即使是bigint (8字节)代理键也不是更好:每行8字节+索引成本为零。
危险场景:所有应用程序代码都是围绕合成密钥编写的，然后在某一天，有人无意中发现了唯一的违反约束的行为，并有一个“聪明”的想法告诉他如何“修复”它:删除唯一的约束！欢庆！应用程序开始工作了！意识到残酷的真相后才到来。
别笑:我见过后几次。
合成钥匙的可行案例
A. 许多字段都处于唯一约束中。我认为:两个字段是可以的，3- so- so，4-5-多-编写所有的AND都很麻烦，而且代码容易出错，所以我会考虑合成键。
B.在唯一约束条件下，字段的长度是很大的。例如，在唯一约束下，varchar和uuid组合在一起，合成整数键类似于优化技术
C.唯一约束下的数据经常更新。然后合成键
唯一约束的规则在系统的生存期内会发生变化。您知道实体是相关的，但是您希望该规则会随着新的业务需求而改变。那么合成钥匙就能解决这个问题。
E. 数据仓库设计为 量纲建模。这类数据库的设计从代理密钥的设计开始。
对于数据库中的所有实体，都需要细粒度的授权()。
摘要
我认为不存在适用于所有情况的这种普遍规则。
合成钥匙有其成本：
- 不要坚持一条规则
- 分析需求
- 数学题
- 从编码的角度考虑
https://stackoverflow.com/questions/69226319
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号