炒冷饭,对于数据库“删除”操作大家平时都是物理删除,还是逻辑删除啊?...

转自:https://www.v2ex.com/t/410612
铺垫

本人不才,不知这个“逻辑删除”词用的对不对,想表达的就是:当删除时只是将 is_deleted 字段设置为 1,而不是真的将这条记录删掉,关键词可能是 logic delete 或 soft delete。


问题
  • 查了一些资料,貌似支持“逻辑删除”观点的人是多数的:

    • 有前辈提到一个观点,真实世界是没有删除的。订单作废,用户禁用,员工离职,文稿废弃,优惠券作废都是状态的变化。所以 SQL 里面 DELETE 在业务场景里都不应该出现。

    • 为了安全,生产环境不能有人或有程序是对数据库的表有 DELETE 权限的。

  • 反对的声音还是有的:

    • 逻辑删除的设计还会导致常用的 unique key 失效(当然用户可将数据行中原来的码和 is_deleted 一起作为 unique key,但是这样又会出现,再次删除时,系统中无法出现两个完全相同的 ID,又都是 is_deleted=1 的记录出现)。

    • 被“删除”的这条记录如果在业务中与大量的表有关联关系,那么在删除它时,就会引发很多的级联的更新,或者判断引用并提示用户无法修改正被引用的资源。而要保证这些全部更新无误,又要求事务一定可靠,若产生了状态不一致,那么这些“脏数据”的维护也是很痛苦的。

    • 当表中的记录数越来越大时,查询起来会越来越慢。


求解

我能理解具体问题需要具体分析,是要“逻辑删除”还是“物理删除”,主要还是要根据实际的业务场景,比如互联网企业搜 /收集的个人信息、电商类平台用户的订单、金融类平台的交易记录,肯定是不能删除的。但是对于一些维护中间状态的数据,如果可以通过记录日志实现“留档”那么就可以真的删掉它。

不知道有没有那种开源组件,可以_自动实现_当我从一个表中物理删除一条记录时,它可以帮我将它转移到备份表中,我看了一个 MySQL 的审计插件,但是好像并不做这个用途的。或者有类似“ commit log ”那种东东,删除时只需要记录一个 log,有需要的时候可以从日志中恢复回来。


参考

下附几个我搜过的资料,希望能帮助和我一样迷茫的童鞋:

  1. “别删除数据” http://www.infoq.com/cn/news/2009/09/Do-Not-Delete-Data

  2. “逻辑删除真的不是一个好的设计 - 简书” http://www.jianshu.com/p/f37281576585

  3. “ MySQL 删除数据是加一个字段做标记,还是将删除的数据插入到另外一张备份表里,哪种方案更好? - V2EX ”https://fast.v2ex.com/t/406208

  4. “不做显式删除,而用 status=0 代替,是好的实践么? - V2EX ” https://www.v2ex.com/t/363226

转载于:https://www.cnblogs.com/RyanJin/p/10578371.html

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值