关联两个表时，是应该单独执行复合键还是主/外键？

Question

表示两个表之间关系的行业设计标准是什么？您应该使用复合密钥，还是主键和外键分开？这两个选项之间是否存在性能差异？

例如，表示您拥有一个用户，该用户可以拥有零个或多个订单。您的用户表包含属性PK UserID和Name。没有用户，订单永远不会存在。现在，这就是我的问题的主要内容......

1. 您是否遵循第一个图表，其中在OrderID和UserID之间使用了复合键？

2. 或者，您是否遵循第二个图表，其中没有复合键，而订单只是由OrderID标识为FK UserID到用户表？

Answer 1

一般规则是“尽可能缩小您的密钥，除非您明确要求扩展密钥”。

典型情况

按照您的示例，当您开始设计OrderDetails表时，使用设计1，您的选项是：

1. 将整个PK OrderId, UserId迁移到子表或
2. 将一些单列备用密钥引入Orders表，并引用此AK而不是PK。

如果您确实需要订单详细信息中的用户（这是极不可能的），那么前一个架构很好，但您可能没有。此外，如果您需要实现“更改订单的所有权”等功能，使用第一种方法，您会发现任务突然变得比通常应该更复杂。

因此，在绝大多数情况下，后一种设计是一种方法。

极端情况

假设您有一些特殊的业务要求，请说：

  

对于每个用户，订单号码应该形成一个独立于任何其他用户订单的序列。

看起来像设计1的合理理由，不是吗？嗯，是的，不。当然，您必须创建一个由UserId, OrderId组成的复合键，以便不同用户可以重复使用订单号：

1. 这样的密钥不一定是主键。此外，您不必通过子表中的任何外键来引用它。只需创建一个代理Id bigint identity(1,1) primary key并从任何地方引用它。
2. 规则“不更新密钥，或至少不引用可更新密钥”仍然有效。如果密钥可能是可更新的，那么它是被外键引用的非常差的候选者。