软删除方案选型：应保留deleted_flg与effective_end_date两者还是其一

结论优先 #

没有统一标准答案，完全取决于你的数仓业务需求、建模规范和链路改造成本，三类选择的适用场景如下：

仅保留deleted_flg即可的场景 #

• 仅需要区分记录是否有效，没有任何追溯记录具体删除时间的需求
• 下游所有查询、ETL逻辑已经完全适配deleted_flg，改造成本极高，且没有新增时效类分析的规划
• 对应表数据量极大，冗余字段会带来明显的存储成本提升，且存储空间优先级高于字段扩展性

仅保留effective_end_date更合适的场景 #

• 有追溯删除时点的需求，比如统计每日删除的业务记录量级、分析业务操作的时间分布
• 你的数仓采用拉链表建模规范，effective_end_date本身就是拉链表的标准字段，可同时支持全量快照生成、历史状态回溯、有效记录筛选三类需求，筛选有效记录仅需加WHERE effective_end_date IS NULL的条件，完全可以替代deleted_flg的作用
• 后续有缓慢变化维的管理需求，该字段可以直接复用，不需要额外新增字段来记录版本失效时间

同时保留两个字段的适用场景 #

• 过渡期需求：切换字段方案的过程中，上下游需要兼容旧逻辑，等所有链路都适配effective_end_date之后再下线deleted_flg即可
• 特定查询性能优化需求：如果你的表没有对effective_end_date建索引，deleted_flg作为布尔类低基数字段，加索引后的筛选效率会比IS NULL判断更高，适合高频查询有效记录的场景
• 业务规则要求必须单独标记删除状态，避免effective_end_date因为其他业务逻辑（比如记录更新、版本迭代）被赋值，导致删除状态判断出错

注意：如果同时保留两个字段，必须新增一致性校验规则，避免出现deleted_flg = 1但effective_end_date IS NULL、或者deleted_flg = 0但effective_end_date 非空的不一致情况，否则会给下游数据应用埋坑。

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