JPA继承中子类关联对象删除时如何级联删除父类？继承方式是否合理？

一、实现级联删除父类Notification实例 #

当前删除AssetSurvey时仅删除子类AssetSurveyNotification但残留父类Notification记录，可通过以下方式解决：

1. 数据库层面配置级联删除（推荐） #

JOINED继承策略下子类表通过外键关联父类主键，可在子类实体添加数据库级联删除注解（以Hibernate为例），让数据库自动清理关联的父类记录：

@Entity
@PrimaryKeyJoinColumn(name = "notification_id", referencedColumnName = "id")
@OnDelete(action = OnDeleteAction.CASCADE) // 触发数据库级联删除父表记录
public class AssetSurveyNotification extends Notification {
    @OneToOne(mappedBy = "notification", cascade = CascadeType.REMOVE)
    private AssetSurvey assetSurvey;
    // 子类其他字段
}

该方式由数据库引擎处理，性能可靠，避免应用层级联可能出现的懒加载遗漏问题。

2. 确保应用层完整删除子类实体 #

若依赖JPA应用层级联，需保证删除AssetSurvey时能完整加载AssetSurveyNotification实体：

• 将关联的fetch类型设为EAGER：

@Entity
public class AssetSurvey {
    @OneToOne(cascade = CascadeType.REMOVE, fetch = FetchType.EAGER)
    private AssetSurveyNotification notification;
    // 其他字段
}

删除AssetSurvey时，JPA会加载完整的子类实体，进而触发父类Notification记录的删除。

3. 手动补充删除（备选兜底） #

若上述方法无法生效，可在删除AssetSurvey后手动清理对应父类记录：

// 删除AssetSurvey后执行
AssetSurveyNotification notification = assetSurvey.getNotification();
if (notification != null) {
    entityManager.remove(notification);
}

二、InheritanceType.JOINED继承策略是否适合多通知类型共用API的场景 #

当前策略是合适的，具体分析如下：

核心优势 #

1. 数据规范化：父表notification存储所有通知的通用字段（如创建时间、状态、接收人），子表仅存各类型特有字段，无数据冗余。
2. API复用性强：可基于父类Notification编写通用接口（如查询所有通知、更新通用状态、按ID获取通知），无需为每种类型单独开发API。
3. 面向对象特性：子类继承父类的方法与字段，便于扩展各通知类型的特有逻辑，同时保持代码一致性。

潜在不足与替代方案 #

• 查询性能：查询子类通知需关联父表与子表，性能略逊于SINGLE_TABLE策略。若通知类型的特有字段极少，可改用SINGLE_TABLE（单表存储，通过鉴别器列区分类型），但会带来字段冗余。
• 扩展灵活性：频繁新增通知类型会增加子表数量，但相比TABLE_PER_CLASS（每个子类独立表，父类字段重复），仍更高效且便于统一查询。

若追求极致灵活，也可考虑组合模式：将Notification作为主实体，每种通知类型对应一个关联的扩展实体（如AssetSurveyNotificationExtension），通过@OneToOne关联。但此方式会增加API处理关联实体的复杂度，不如继承策略简洁。

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