数据的软删除—什么时候需要？如何去实现？.pdfVIP

数据的软删除—什么时候需要？如何去实现？ 阅读完本⽂你将会学会 什么是软删除？ 如何考量是否使⽤软删除 如何在Spring⾥实现软删除 1. 前⾔ 我们在开发程序的过程中，会遇到⼀个常见的需求——删除表中的数据。 但是有时候，业务需求要求不能永久删除数据库中的数据。⽐如⼀些敏感信息，我们需要留着以⽅便做历史追踪。 这个时候，我们便会⽤到软删除。 那么什么是软删除？什么时候才能使⽤它？在本⽂中，笔者将会带你学习软删除以及如何⽤Spring Data JPA实现它。 2. 什么是软删除（Soft Delete）？ 2.1 软删除的概念 软删除（Soft Delete）是相对于硬删除（Hard Delete）来说的，它⼜可以叫做逻辑删除或者标记删除。 这种删除⽅式并不是真正地从数据库中把记录删除，⽽是通过特定的标记⽅式在查询的时候将此记录过滤掉。虽然数据在界⾯上已经看不见，但是 数据库还是存在的。 2.2 软删除的实现⽅式 1. 添加布尔类型的字段 添加类似于 is_deleted 或者 is_active 或者 is_archived 的布尔型字段，以此来标记是否删除。 2. 添加时间戳字段 添加类似于 deleted_at 的时间戳字段，null表⽰未删除，⾮null则表⽰已经删除，也能获取删除的时间。 3. 将软删除的数据插⼊到另⼀个表中。 举个例⼦， order 表会有⼀个相应的 order_deleted 表，在删除 order 表中的数据，将数据复制到 order_deleted 表中。 在以上三种⽅式中，第 1种⽅式算是最普遍的，也较为简单； 第2种⽅式虽然对于第 1种⽅式会更加严谨⼀点，因为它可以获取准确的删除时间。但是第2种⽅式在查询的性能⽅⾯却是⽐较差的，因为null值会 导致全表扫描，导致查询效率⼤打折扣。 我们可以混⽤第 1种和第2种⽅式，只⽤第 1种⽅式来做条件，再⽤第2种⽅式的删除时间做补充。 第3种⽅式，思路与前两种⽅式完全不同，当数据量⼤的时候，我们可以考虑采⽤这⼀策略。 2.3 是否采⽤软删除的考量 其实在业务逻辑中采⽤“删除”这个词是不准确的。 ⽐如说，我们“删除”某种产品的时候其实是指我们“停售”了。可能以后不会再卖这种产品了，顾客搜索也不会看见这种商品，但是管理仓库的 ⼈暂时还需要管理它的库存。 所以，“删除”是不准确的说法，只是为了图⽅便。 按照Udi Dahan的解读来看： 订单不是被删除的，⽽是被“取消”的，订单取消得太晚，还会产⽣花费； 员⼯不是被删除的，⽽是被“解雇”的或者“退休”的。还有相应的补偿⾦要处理； 职位不是被删除的，是被“填补”的（或者招聘申请被驳回）。 真实的世界并不是级联的 假设市场部要从商品⽬录中删除⼀样商品，那是不是说所有包含了该商品的旧订单都要⼀并消失？再级联下去，这些订单对应的所有发票也要删除 吗？就这么⼀步步删下去，是不是公司的损益报表也要重做了？ 这样看起来明显不合理吧。 那我们在实际的业务逻辑中是否采⽤软删除？ 软删除的好处显⽽易见，它是⼀味后悔药，利于历史追踪或者为了审计⽬的（History tracking or audit）。 当然软删除也有弊端，不利于数据库性能（主要针对关系型数据库）的提升，可能会产⽣⼤量的冗余数据。 如果我们不需要，请不要画蛇添⾜，当我们需要的时候，请考虑业务的数据量和读写⽅式。 当需要软删除的时候，我们设置⼀个状态字段，⽤来表⽰数据是否还有效。当然，我们也可以采⽤⼀个拥有多重状态的字段：有效、停⽤、取消、 弃置等等。我们可以借助这样⼀个状态字段来回溯过去的字段，以此进⾏分析。 3. 在Spring中实现软删除 在Spring Data JPA的帮助下，实现软删除变得⾮常简单。我们只需要添加⼀些注释即可。 现在让我们来看看如何实现这⼀功能： 3.1 实体类 Product 清单3.1.1 实体类Product package com.jayxu.mydemo.persistence.entity; import javax.persistence.Entity; import javax.persistence.Table; @Entity @Table(name = product) public class Product { private long id; private String name; private double price; private String desc