外键作为主键，或者只是与JPA上下文中的外键不同的单独代理主键

Question

在JPA上下文中，将FK用作PK或将代理PK和FK用作FK的最佳实践是什么？ 我很少见到有人说他们必须将FK映射为PK，因为他们拥有旧数据库。 因此，这是否意味着对于新表，如果可以控制创建它们，则最好使用以下结构：

TABLE_1
-------
ID (PK)
...

TABLE_2
-------
ID (PK) 
TABLE_1_ID (FK)

代替：

TABLE_2
-------
TABLE_1_ID (PK) and (FK)

Answer 1

对于多对一关系，请始终使用您提出的第一种选择。

对于某些一对一的关系，可以合并表而不会产生不良影响。

如Martin Fowler所述，在使用类表继承模型实现超类-子类层次结构时，第二种选择真正有用的地方。 在这种情况下，您要使子类表与超类表保持不同，以减少NULLS的数量。 但是这种关系是一对一的。

通过在子类表中使用与PK和FK相同的键功能，并通过使FK引用超类表中的匹配条目，可以在需要时将专用数据与通用数据连接起来变得非常容易。 这可以称为“穷人的继承”。

Answer 2

在这种特殊情况下（1到0..1关系），请考虑将两个表合并为一个。

如果有意将它们拆分（例如，用于“垂直”分区），则最好将同一字段同时用作PK和FK。

仅在可以将其减小为^{1的情况下} ，才考虑添加另一个键，但要与其他索引^2的需求，对集群的潜在敌意³以及对菱形依赖项进行建模^4加以平衡。

¹ 例如，因为TABLE_2.TABLE_1_ID是字符串，所以您可以使TABLE_2.ID整数。

² 每个新索引都会减慢INSERT的速度，并且可以减慢UPDATE和DELETE的速度，具体取决于它们的WHERE子句。 另外，任何其他数据都会对缓存施加额外压力，使其“更小”。

³ 聚簇表中的二级索引需要包含PK的副本，并且在查找行时可能导致双重查找（首先是索引，然后是PK）。

⁴ 为了确保钻石的“底部”引用单个 “顶部”，可能有必要在“钻石”的两个“边缘”上使用识别关系。

Answer 3

我想您正在寻找@MapsId注释。