在什么情况下我们需要在数据库中使用复合键
我已经看到我们可以拥有复合键，其中主键由两个表的组合主键组成。
喜欢的人和书
person_id and book_id will make the primary key.
但我想问的是，我们需要对编程语言进行硬编码
我的意思是可以，我可以有任意名称的单独列作为主键，然后我不必对其进行硬编码，并且可以像平常一样执行我的功能
id,person_id ,book_id
-
在“新”应用程序中不应考虑使用组合键。过去，曾经有人认为“业务密钥”比“代理密钥”更好。
编辑：按照克里斯的要求，我正在扩大答案。
首先，我要说明我将这个问题理解为“复合主键”与“代理键”。
另外，我也承认在 一个
用例中复合键很有意义：在交叉引用表（也称为“链接表”）中。这些用于多对多表，仅包含两个字段，两个外键均构成外部参照表的主键。例如，UserRole表将包含user_id和role_id，仅此而已。例如，对于Java这样的表，没有类表示形式。通常是a
@ManyToMany，Collection两边都有a 。我在另一个答案（Hibernate：CompositePKvsSurrogatePK中的观点）中分享了我对Natural键与Surrogate键的看法，并且我相信Composite键在没有带来任何实际好处的情况下也具有Natural键的一些缺点。
复合键的问题在于，您将需要_两个_值来唯一地标识一条记录。一旦开始拥有引用该第一个表中的记录的表，这将成为一个问题。然后，第二个表需要 两
列才能引用 一条 记录。并且，如果第二个表使用由单个值+外键组成的复合键，则您现在具有 三 列来唯一地标识 一条 记录。第三张表将需要这 三_列额外的列，以仅引用第二张表中的 _一条 记录。真的，这是雪球。另一个缺点是需求 确实会 发生变化。每时每刻。因此，今天看来是好的组合键并不是明天的所有键。这就是我们拥有替代钥匙的原因：要面向未来。
复合键主要用于使表中的记录基于一组列而唯一。例如，如果您有一个
Customers表，则可能有一个NationalId+Country作为唯一值，这意味着如果两个用户所在的国家/地区是美国，则两个用户不能共享相同的SSN。但是，如果两个记录不在同一国家/地区，则它们的编号可能相同。如果您喜欢组合键，那么这将是一个不错的选择。但是正如我之前所暗示的，您可以使用代理键并应用unique约束。您将拥有复合钥匙的优势以及代理钥匙的安全性。
