数据库物理删除与逻辑删除

勤奋不是嘴上说说而已,而是实际的行动,在勤奋的苦度中持之以恒,永不退却。业精于勤,荒于嬉;行成于思,毁于随。在人生的仕途上,我们毫不迟疑地选择勤奋,她是几乎于世界上一切成就的催产婆。只要我们拥着勤奋去思考,拥着勤奋的手去耕耘,用抱勤奋的心去对待工作,浪迹红尘而坚韧不拔,那么,我们的生命就会绽放火花,让人生的时光更加的闪亮而精彩。

导读:本篇文章讲解 数据库物理删除与逻辑删除,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com,来源:原文

概念

逻辑删除:文件没有被真正的删除,只不过是文件名的第一个字节被改成操作系统无法识别的字符,通常这种删除操作是可逆的,就是说用适当的工具或软件可以把删除的文件恢复出来。

物理删除:指文件存储所用到的磁存储区域被真正的擦除或清零,这样删除的文件是不可以恢复的,物理删除是计算机处理数据时的一个概念。

逻辑删除就是对要被删除的数据打上一个删除标记,在逻辑上是数据是被删除的,但数据本身依然存在!而物理删除则是把数据从介质上彻底删除掉。

自己理解:
1、比如磁盘中的文件删除,在删除操作时,只是在文件分配表FAT中做一个删除标记,但磁盘扇区中的文件数据依然存在,这就是逻辑删除!而物理删除,则是一些软件在删除时采用一些特定的算法,对删除文件所在的扇区反复读写,以达到彻底删除的目的。至于写文件时,扇区的分配则是随机的。逻辑删除的文件容易恢复,而物理删除则很难恢复!
2、就比如删除东西的时候,逻辑删除的时候,没有删除数据库里的数据,所以逻辑删除可以恢复。当物理删除的话,就是把数据库里的数据也删除,所以没办法恢复。
3、最主要的区别就是能恢复和不能恢复。

区别

  • 物理删除是计算机处理数据时的一个概念。
  • 逻辑删除就是给要删除的数据打上一个删除标记,在逻辑上是数据是被删除的,但数据本身依然存在(这行记录还是存在的),而物理删除则是把数据从存储介质上彻底删除掉。
  • 逻辑删除的文件容易恢复,而物理删除则很难恢复!
  • 数据库中的删除操作一般是逻辑删除,被删除的那行记录仍然是存在的。

其他

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

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

反对采用逻辑删除的:

  • 逻辑删除的设计还会导致常用的 unique key 失效(当然用户可将数据行中原来的码和is_deleted 一起作为 unique key,但是这样又会出现,再次删除时,系统中无法出现两个完全相同的 ID,又都是is_deleted=1的记录出现)。
  • 被“删除”的这条记录如果在业务中与大量的表有关联关系,那么在删除它时,就会引发很多的级联的更新,或者判断引用并提示用户无法修改正被引用的资源。而要保证这些全部更新无误,又要求事务一定可靠,若产生了状态不一致,那么这些“脏数据”的维护也是很痛苦的。
  • 当表中的记录数越来越大时,查询起来会越来越慢。

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

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

别删除数据

逻辑删除真的不是一个好的设计

MySQL 删除数据是加一个字段做标记,还是将删除的数据插入到另外一张备份表里,哪种方案更好? – V2EX

不做显式删除,而用 status=0 代替,是好的实践么? – V2EX

参考

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/142381.html

(0)
飞熊的头像飞熊bm

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!