在数据库表中,添加 is_deleted 字段以实现软删除是一个广泛接受的最佳实践。然而,我认为,这个技术解决方案并不全面地覆盖所有业务场景。我们在讨论是否使用 is_deleted 列时,可能忽略了关键的业务概念。当然还有其他软删除的方式。 对于一个业务是否需要软删除,还是直接物理删除,需要对一个场景进行分析。
那么在业务处理中应该一味的选择软删除可行吗?答案当然是否定的。
软删除(逻辑删除)的弊端
软删除,也称为逻辑删除或标记删除,是一种通过修改数据库记录的某个字段来标记记录为已删除,而不实际从数据库中删除记录的方法。这种技术提供了数据恢复的可能性,并且可以保留历史数据以供分析和审计之用。然而,软删除也存在一些弊端,主要包括以下几点:
存储开销:软删除的数据仍然占用数据库空间,这可能导致存储效率降低 。
查询性能:需要在查询操作中过滤掉标记为删除的数据,这可能会降低数据库的查询性能 。
唯一索引问题:在软删除模式下,唯一索引可能难以正确工作,因为无法将已标记为删除的记录的特定字段更新为其他值,这可能导致违反唯一性约束 。
外键约束失效:软删除可能会使得外键约束无法正常工作,因为外键约束通常依赖于记录的存在与否,而不是其删除状态 。
复杂查询:在软删除模式下,原本简单的SQL查询可能变得复杂,需要添加额外的条件来排除已软删除的记录 。
数据堆积:由于软删除不会真正删除数据,长时间累积可能会造成数据堆积,影响数据库性能 。
看到这么多弊端可能又有人会说,那我直接用硬删除得了,是的硬删除可能
不会有上述的弊端但是也会出现,其他弊端。
硬删除(物理删除)的弊端
硬删除,即物理删除,是从数据库中彻底移除数据的过程。一旦数据被硬删除,除非有数据备份,否则这部分数据将无法恢复。虽然硬删除可以提高数据库的性能和数据管理的简洁性,但它也有一些弊端:
不可恢复性:硬删除的最大弊端是数据一旦被删除,就无法恢复,这可能导致重要数据的永久丢失。
数据丢失风险:操作错误可能导致重要数据的丢失,这种风险在没有适当备份的情况下尤其严重。
法律和合规性问题:在某些行业,数据保留是受到法律或合规性要求的,硬删除可能违反这些规定。
审计和历史分析困难:硬删除后,历史数据无法用于审计或分析,这可能影响企业的决策和运营。
数据一致性问题:在涉及复杂关系数据库的情况下,硬删除可能破坏数据的一致性,特别是当存在外键约束时。
看到这里,就会觉得这也不行,那也不行。那我还要不要执行删除指令了。
刚刚之前就提过,删除还是要删除的,具体用什么删除主要,要看业务使用场景,什么业务场景,就要用到什么删除,世界不是非黑即白的世界,技术也不是只有一种实现方式,像is_delete这种标记方式会存在一些问题,但是呢,还有其他平替的软删除法,但是也有弊端。所以作为一个码农,只从技术角度去考虑问题是不行的,所以我们要从实际出发。
业务场景
产品下架与重新上架
在商品管理方面,卖家可能由于各种原因(如库存不足、产品更新、季节性调整等)需要暂时将商品下架。如果直接删除商品信息,当需要再次上架时,卖家需要重新输入所有商品详情,这不仅效率低下,还可能导致信息丢失或不一致。通过使用软删除,卖家可以轻松地将商品标记为“下架”,保留其所有信息,并在需要时快速重新上架,无需重新输入数据。
这就需要利用标记的模式把它删除,便于商品的管理。
所以,有一个业务思路:
订单不是被“删除”,而是被取消,而且如果取消的时间过晚,可能还会产生额外的费用。
员工不是被“删除”,而是被解雇或者退休,这往往还涉及到如何处理员工的离职赔偿。
工作岗位也并非被“删除”,而是被填满,或者需求被撤销。
以上这些仅仅只是一部分业务,还有更加复杂的业务模式,可能就要用到软硬结合的方式。
软删除说完了,在来说一下硬删除的商业模式,如果业务人员明确说明以后都不会用到,且对事务法律没有任何影响的情况下,我们最好还是用硬删除,因为程序员最大的快乐,难道不是删库跑路吗。这当然只是开玩笑的。我想说的是,如果有备份数据库,那么就可以使用硬删除,或者在这个主业务表中删除的同时,安排一个同样的字段的表来接收,这样同时减少了数据库查询的压力,也完成了删除。但是这也多出来了一步插入语句,不过这种方式。还是可以接受的,这就要辛苦程序猿了。
综上所述,一般的业务情况下都喜欢用个is_delete来偷会儿懒,但是如果涉及到千万级别的数据量,那这个偷懒行为,你就要付出代价了。所以,不要只想一招吃遍天,那是不可能的事。