Java 如何在JPA实体中优化模型继承

我想知道，如果JPA实体不共享主键，那么在JPA实体中使用继承的最佳实践是什么，特别是如果数据库已经存在并且不能轻易更改的话

假设我们有一个员工数据库，就像在。现在，这个数据库不太现实。工资通常随时间而变化，我们将跟踪工资的变化。例如，工作合同可能会说，每年12月，员工都会与经理会面，讨论下一年的工资

因此，我们将从HR.EMPLOYEES中删除工资字段，并创建一个新表HR.SALARIES：

EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)

主键将由员工ID和有效来源组成

所以，现在，如果帕特在12月与她的经理迈克尔会面并就新的工资达成一致，我们将在人力资源部的工资中插入一个新的记录

现在，让我们假设人力资源部在输入新数据时犯了一个错误，因此Pat在一月份得到的工资不正确。她向老板报告问题，老板联系人力资源部，他们更正人力资源部的工资记录。她将在2月份的付款中收到丢失的金额

年末，公司接受审计。审计员想知道为什么一月份发给帕特的工资支票与数据库中的工资条目不匹配。为了确保审计人员始终能够理解系统为什么做出某些决定（例如签发一定金额的支票），我们需要保留更改历史记录

将人力资源工资更改为：

EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)
CHANGE_DATE NOT NULL DATE

添加新表HR.SALARIES\u CHANGE\u HISTORY:

EMPLOYEE_ID NOT NULL NUMBER(6)
VALID_FROM NOT NULL DATE
SALARY NUMBER(8,2)
CHANGE_DATE NOT NULL DATE

主键由员工ID、有效起始日期和更改日期组成

出于绩效原因，我们将变更历史记录保存在一个单独的表格中：我们的人力资源系统几乎不会读取它

现在我们终于来回答我的问题了。我们如何在JPA中对该数据库进行最佳建模，以及我们能否以某种方式利用继承，因为表HR.palaries和HR.palaries\u CHANGE\u HISTORY是相同的，只是CHANGE\u DATE是HR.palaries\u CHANGE\u HISTORY中主键的一部分

JavaEE中有@MappedSuperclass，一开始听起来不错，但是在使用@MappedSuperclass的类层次结构中不可能使用不同的主键（请参阅和）

---

是否有任何方法可以避免实体bean中工资和工资变更历史的代码重复

你对“重复”的定义太过分了。如果您有两个几乎相同的表，那么拥有两个几乎相同的实体是完全合理的。使用Lombok时，您几乎不应该有任何代码可言。@Gimby:我不同意这一点。如果从业务的角度来看两个实体是相关的，那么该关系应该在代码中可见。工资变化历史是工资的延伸，因此我们应该能够使用继承。