Database design 外键作为主键，或者只是将代理主键与JPA上下文中的外键分开

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

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

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

而不是：

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

在这种特殊情况下（1到0…1的关系），考虑将两个表合并为一个。< /P> 如果它们是有意分割的（例如，为了“垂直”分割），则希望相同的字段同时为PK和FK

只考虑添加另一个键，如果你能使它更小，但要平衡它，需要额外的索引2，对3的潜在敌意和需要对钻石形状的依赖性进行建模。

---

1例如，因为

TABLE_2.TABLE_1.ID

是字符串，您可以将

TABLE_2.ID

设置为整数

2每个新索引都会减慢插入速度，并会减慢更新和删除速度，具体取决于它们的WHERE子句。此外，任何额外的数据都会对缓存施加额外的压力，使其“更小”

3聚集表中的二级索引需要包含PK的副本，并且在定位行时可能会导致双重查找（先查找索引，然后查找PK）

---

4可能需要在“菱形”的两个“边”上使用标识关系，以确保菱形的“底部”引用单个的“顶部”。

对于多对一关系，始终使用您介绍的第一个备选方案

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

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

---

通过在子类表中创建与PK和FK相同的键函数，并通过使FK引用超类表中的匹配项，可以在需要时非常容易地将专用数据与通用数据连接起来。这可以称为“穷人的遗产”

我猜您正在寻找

@MapsId

注释