我认为使用复合键没有问题。
对我来说，数据库本身就是一个组件，应该像对待代码一样对待它：例如，我们想要干净的代码，可以清楚地传达其意图，可以做一件事并且做得很好，不会添加任何内容不需要的复杂性等
与db相同，如果PK是复合的，则这是现实，因此模型应保持整洁。复合PK比混合自动增量+约束更清晰。当您看到没有任何作用的ID列时，您需要询问什么是真正的PK，您还应该知道其他隐藏的东西，等等。清晰的PK不会留下任何疑问。
数据库是您应用程序的基础，对我而言，我们需要可以拥有的最坚实的基础。在此基础上，我们将构建应用程序（是否通过网络）。所以我看不到为什么我们应该弯曲数据库模型以使其符合一种开发工具/框架/语言中的某些特定要求。数据在指导应用程序，而不是相反。如果ORM在将来发生变化并变得过时并且出现了强加另一个模型的更好解决方案，该怎么办？我们无法使用db模型来适应这个框架或那个框架，该模型应该保持不变，它不应该依赖于我们用来访问数据的工具…
如果将来更改数据库模型，则应该更改，因为功能已更改。如果今天我们知道此功能的变化方式，我们将对此进行建模。将来，任何将来的更改都将得到处理，例如，我们无法预测对现有数据的影响，因此，额外的一栏并不能保证它会撤销任何将来的更改…
我们应该针对当今的功能进行设计，并保持db模型尽可能简单，这样将来将来更改/发展就很容易。
