我们知道,如果在业务界面上删除一条数据,通常的做法是与后台通信,从数据库表中删除掉这一条记录,这种方式通常被称为硬删除。然而这种方式会带来一个弊端,即数据一旦删除了,就真的永久删除了,没有后悔药可以吃,也没有办法恢复。这样,在一些场景中,比如需要保留用户删除的痕迹或能够恢复删除的数据的时候,硬删除就没有办法满足需求了。因此,相对于硬删除,聪明的人们又想到了软删除。
软删除的概念
软删除又叫逻辑删除或标记删除,是一种对立于硬删除的删除方式。这种方式并不是真正的从数据库表中把记录删除,而是通过特定的标记方式标记此记录已被删除(在查询的时候过滤掉此记录),这样用户在界面上看起来就像是数据真的被删掉了,然而事实上却是库里还在,甚至明天还想再见他。
软删除的实现方式
软删除的实现通常有三种:
1.在表里添加布尔类型的字段,标记该记录是否被逻辑删除。
2.在表里添加删除时间(默认为null),如果有删除时间则表示此记录被逻辑删除,和第一种方式大差不差。
3.将逻辑删除的数据插入到另外一个表里。
在上面的3种实现方式里,第1种方式算是最普遍的,也较为简单。而第2种方式虽然相对于第一种方式来说会更严谨一些,因为还能有准确的删除时间,但是在查询的性能方面却是比较差的,因为null值会导致全表扫描,导致查询效率大打折扣。更聪明的做法可以将第1种方式和第二种方式混用,即只用第一种方式的字段做条件,这样逻辑上会更严谨一些,也不会影响查询性能。而第3种方式则其实是稍微有些偏离了软删除的概念,因为数据实际上还是从原来的表中删除掉了,但是这种方式因为相当于对删除的数据做了数据分离,因此在数据量比较大的情况下对数据库性能会有一定的提升。
设计软删除的原则与总结
在设计软删除的时候,一定要考虑业务上是否一定需要软删除,如果不需要请不要画蛇添足。
当在业务上需要软删除的情况下,就要开始考虑业务的数据量和读写的比例,从表数据量的角度去分析、优化数据库的性能,就像上面说的那样选择不同的实现方式。
虽然软删除从逻辑上看更加严谨,且能够保证数据的完整性,但这并不代表我们在任何时候都要使用软删除。当我们确定某些数据真的不需要的时候,硬删除是十分必要的,因为这样能减少数据库表中的记录数量,有效提升数据库性能。
"人若能够耐得住寂寞,就能够少受许多痛苦和少出许多洋相。许多人的痛苦,都是因为不甘寂寞。"