在“新”应用程序中不应考虑使用组合键。过去，曾经有人认为“业务密钥”比“代理密钥”更好。

编辑：按照克里斯的要求，我正在扩大答案。

首先，我要说明我将这个问题理解为“复合主键”与“代理键”。

另外，我也承认在 一个
用例中复合键很有意义：在交叉引用表（也称为“链接表”）中。这些用于多对多表，仅包含两个字段，两个外键均构成外部参照表的主键。例如，UserRole表将包含user_id和role_id，仅此而已。例如，对于Java这样的表，没有类表示形式。通常是a
@ManyToMany，Collection两边都有a 。

我在另一个答案（Hibernate：CompositePKvsSurrogatePK中的观点）中分享了我对Natural键与Surrogate键的看法，并且我相信Composite键在没有带来任何实际好处的情况下也具有Natural键的一些缺点。

复合键的问题在于，您将需要_两个_值来唯一地标识一条记录。一旦开始拥有引用该第一个表中的记录的表，这将成为一个问题。然后，第二个表需要 两
列才能引用 一条 记录。并且，如果第二个表使用由单个值+外键组成的复合键，则您现在具有 三 列来唯一地标识 一条 记录。第三张表将需要这 三_列额外的列，以仅引用第二张表中的 _一条 记录。真的，这是雪球。

另一个缺点是需求 确实会 发生变化。每时每刻。因此，今天看来是好的组合键并不是明天的所有键。这就是我们拥有替代钥匙的原因：要面向未来。

复合键主要用于使表中的记录基于一组列而唯一。例如，如果您有一个Customers表，则可能有一个NationalId+Country作为唯一值，这意味着如果两个用户所在的国家/地区是美国，则两个用户不能共享相同的SSN。但是，如果两个记录不在同一国家/地区，则它们的编号可能相同。如果您喜欢组合键，那么这将是一个不错的选择。但是正如我之前所暗示的，您可以使用代理键并应用unique约束。您将拥有复合钥匙的优势以及代理钥匙的安全性。