关联两个表时，应该做复合键，还是分别做主/外键？

Question

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

例如，假设您有一个用户，该用户可以有零个或多个订单。您拥有具有属性

PK UserID

和

Name

的用户表。没有用户，订单永远不会存在。现在，这就是我问题的核心所在......

1. 您是否遵循第一张图，其中

   OrderID

   和

   UserID

   之间使用了复合键？

2. 或者，您是否遵循第二张图，其中没有复合键，并且订单只是通过

   OrderID

   和 User 表中的

   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. “不要更新密钥，或者至少不要引用可更新密钥”的规则仍然有效。如果该密钥可能是可更新的，那么它就不太适合被外键引用。