是否应该使用复合主键？

Question

在Java的JPA中（通过EmbeddedId或IdClass注释）似乎仅对复合数据库键提供第二类支持。当我阅读复合键时，无论使用哪种语言，人们都会碰到它们，因为这是一件坏事。但是我不明白为什么。如今，组合键是否仍然可以使用？如果没有，为什么不呢？

我发现一个同意我的人：http
:
//weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

但是另一个没有的人：http
:
//weblogs.java.net/blog/bleonard/archive/2006/11/using_composite.html

是我一个人，还是人们无法区分组合键是否合适？当表不代表实体时（即当它代表联接表时），我看到复合主键很有用。

一个简单的例子：

Actor { Id, Name, Email } Movie { Id, Name, Year } Character { Id, Name } Role { Actor, Movie, Character }

在这里，演员，电影和角色显然受益于将ID列作为主键。

但是角色是一个多对多联接表。我发现创建ID只是为了标识数据库中的一行没有任何意义。在我看来，主键显然是{ Actor, Movie, Character }。这似乎是一个相当有限的功能，特别是如果联接表中的数据一直在变化，那么一旦主键序列回绕为0，您就可能会遇到主键冲突。

因此，回到最初的问题，使用复合主键是否仍然可以接受？如果没有，为什么不呢？

Answer 1

我认为使用复合键没有问题。

对我来说，数据库本身就是一个组件，应该像对待代码一样对待它：例如，我们想要干净的代码，可以清楚地传达其意图，可以做一件事并且做得很好，不会添加任何内容不需要的复杂性等

与db相同，如果PK是复合的，则这是现实，因此模型应保持整洁。复合PK比混合自动增量+约束更清晰。当您看到没有任何作用的ID列时，您需要询问什么是真正的PK，您还应该知道其他隐藏的东西，等等。清晰的PK不会留下任何疑问。

数据库是您应用程序的基础，对我而言，我们需要可以拥有的最坚实的基础。在此基础上，我们将构建应用程序（是否通过网络）。所以我看不到为什么我们应该弯曲数据库模型以使其符合一种开发工具/框架/语言中的某些特定要求。数据在指导应用程序，而不是相反。如果ORM在将来发生变化并变得过时并且出现了强加另一个模型的更好解决方案，该怎么办？我们无法使用db模型来适应这个框架或那个框架，该模型应该保持不变，它不应该依赖于我们用来访问数据的工具…

如果将来更改数据库模型，则应该更改，因为功能已更改。如果今天我们知道此功能的变化方式，我们将对此进行建模。将来，任何将来的更改都将得到处理，例如，我们无法预测对现有数据的影响，因此，额外的一栏并不能保证它会撤销任何将来的更改…

我们应该针对当今的功能进行设计，并保持db模型尽可能简单，这样将来将来更改/发展就很容易。