基于JPA继承的实体历史记录持久化方案问询

针对实体历史记录持久化的需求，我们调研Hibernate Envers后发现，全局REVINFO表在适配现有客户系统和性能表现上存在明显瓶颈，因此设计了以下替代方案：

核心设计思路 #

1. 业务实体基础配置 #

• 将每个业务实体（例如CUSTOMER）标注为@MappedSuperclass，其核心业务数据直接存入对应的业务表（如CUSTOMER表）。这种方式能最大程度保留原有业务表的结构和访问逻辑，避免对现有业务代码造成大规模改动。

2. 历史实体的独立设计 #

• 为每个业务实体创建对应的历史子类，比如针对Customer实体，我们创建CustomerHistory子类并继承自Customer
• 在历史子类中添加专属的历史追踪字段：
  • historyId：作为历史表的独立主键，与业务实体的主键完全解耦
  • 时间维度字段：添加开始时间和结束时间，用来标识该版本数据的生效周期（结束时间设为null时表示当前生效版本）
  • 可选扩展字段：根据实际需求添加操作人ID、操作类型（新增/修改/删除）等元数据，便于后续审计追溯

方案优势 #

相比Envers的REVINFO全局版本表方案，这个方案的优势在于：

• 适配性更强：不需要依赖全局版本控制表，完全适配现有客户的数据库结构，不会引入额外的全局关联依赖
• 性能更优：查询历史数据时直接访问对应独立的历史表，无需关联REVINFO表做跨表查询，大幅提升历史数据的查询效率
• 灵活性更高：可以针对不同实体的历史需求定制字段，不需要遵循Envers统一的版本控制规则

内容的提问来源于stack exchange，提问作者Mike Rother