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