本人不才,不知这个“逻辑删除”词用的对不对,想表达的就是:当删除时只是将 is_deleted 字段设置为 1,而不是真的将这条记录删掉,关键词可能是 logic delete 或 soft delete。
查了一些资料,貌似支持“逻辑删除”观点的人是多数的:
有前辈提到一个观点,真实世界是没有删除的。订单作废,用户禁用,员工离职,文稿废弃,优惠券作废都是状态的变化。所以 SQL 里面 DELETE 在业务场景里都不应该出现。
为了安全,生产环境不能有人或有程序是对数据库的表有 DELETE 权限的。
反对的声音还是有的:
逻辑删除的设计还会导致常用的 unique key 失效(当然用户可将数据行中原来的码和 is_deleted 一起作为 unique key,但是这样又会出现,再次删除时,系统中无法出现两个完全相同的 ID,又都是 is_deleted=1 的记录出现)。
被“删除”的这条记录如果在业务中与大量的表有关联关系,那么在删除它时,就会引发很多的级联的更新,或者判断引用并提示用户无法修改正被引用的资源。而要保证这些全部更新无误,又要求事务一定可靠,若产生了状态不一致,那么这些“脏数据”的维护也是很痛苦的。
当表中的记录数越来越大时,查询起来会越来越慢。
我能理解具体问题需要具体分析,是要“逻辑删除”还是“物理删除”,主要还是要根据实际的业务场景,比如互联网企业搜 /收集的个人信息、电商类平台用户的订单、金融类平台的交易记录,肯定是不能删除的。但是对于一些维护中间状态的数据,如果可以通过记录日志实现“留档”那么就可以真的删掉它。
不知道有没有那种开源组件,可以_自动实现_当我从一个表中物理删除一条记录时,它可以帮我将它转移到备份表中,我看了一个 MySQL 的审计插件,但是好像并不做这个用途的。或者有类似“ commit log ”那种东东,删除时只需要记录一个 log,有需要的时候可以从日志中恢复回来。
下附几个我搜过的资料,希望能帮助和我一样迷茫的童鞋:
“别删除数据” http://www.infoq.com/cn/news/2009/09/Do-Not-Delete-Data
“逻辑删除真的不是一个好的设计 - 简书” http://www.jianshu.com/p/f37281576585
“ MySQL 删除数据是加一个字段做标记,还是将删除的数据插入到另外一张备份表里,哪种方案更好? - V2EX ” https://fast.v2ex.com/t/406208
“不做显式删除,而用 status=0 代替,是好的实践么? - V2EX ” https://www.v2ex.com/t/363226
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.