无外键关联场景下如何实现父表删除时级联删除子表记录

原生级联删除能力的生效，完全依赖数据库层面已建立的、带参照完整性校验的正式外键约束，在你当前的表结构状态下，存在两个硬阻断因素，导致级联逻辑完全无法触发：

1. 两个表之间没有建立任何正式的外键关联约束，数据库完全无法识别父表和子表的关联关系，不具备触发自动级联的基础；
2. 当前Table1中用于关联子表的ChildId字段为可空类型，就算后续补建外键，不匹配约束校验规则的可空字段也无法正常驱动级联删除的触发逻辑。

就算是在ORM框架层面配置了Cascade Delete规则，本质上也只是框架自行生成顺序删除的SQL语句，并非数据库原生能力，在当前表结构设计不规范的场景下，很容易出现配置失效、残留孤儿关联数据的问题。

结合当前表结构的现存问题，可根据业务的调整成本选择对应方案：

• 方案1：补建合规的外键约束，开启数据库原生级联规则
  先完成前置数据校验：排查所有ChildId值，确认不存在和子表主键不匹配的脏数据，再根据业务场景调整ChildId的可空属性（如果业务允许父记录无关联子表，可保留可空属性但明确校验规则），最后正式建立两表的外键关联，在约束配置中启用ON DELETE CASCADE规则。这是长期维护成本最低的方案，能从根源修正当前表结构的设计缺陷，数据一致性的保障能力最强。
• 方案2：在应用层封装统一的删除入口逻辑
  暂时不方便调整表结构约束时，可在所有涉及删除父表记录的业务代码路径中，前置增加关联子表的删除逻辑：删除父表记录前，先根据当前父记录的ChildId值删除子表中匹配的记录，再执行父表记录的删除操作。该方案的局限性很明显：如果存在多入口删除父表的逻辑，很容易出现漏写子表删除分支的问题，最终产生无法追溯的孤儿数据。
• 方案3：在数据库层配置删除触发器
  给父表创建删除触发器，当父表执行DELETE操作时，触发器自动捕获当前被删除记录的ChildId值，自动执行子表的匹配记录删除操作。该方案不需要修改应用层代码，对现有业务逻辑的侵入性低，但需要严格校验触发器的判断逻辑，避免误删存在其他业务关联的子表记录。
• 方案4：改用软删除逻辑替代物理硬删除
  给父表和子表都增加IsDeleted标记字段，所有删除操作仅将对应记录的标记位更新为已删除，查询时统一过滤已标记为删除的记录。这种方案完全不涉及物理数据删除，自然不需要处理关联数据的同步删除问题，但会让查询逻辑逐步叠加过滤条件，长期数据量增长后会持续影响查询性能。

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