文章目录
- 前言
- 一、逻辑删除、唯一索引一起使用(不推荐)
- 二、使用物理删除、并加唯一索引
- 使用逻辑删除,不加唯一索引
前言
唯一索引、逻辑删除,相信这两个词对于java程序员来说一点都不陌生吧。
唯一索引:索引列的值必须是唯一的,不允许重复
逻辑删除:用字段的状态记录数据是否被删除
最近项目上遇到因为没有正确使用这两个东西,导致一系列的问题。比如删除的时候逻辑删除,并且比如身份证号,手机号又加了唯一索引,再次保存就报错。有些项目从业务上来讲身份证,手机号必须唯一但是没有加唯一索引,但是产生了很多重复数据,今天就来分析一下什么场景下使用这两个东西。
一、逻辑删除、唯一索引一起使用(不推荐)
不建议一起用,除非项目开发前经过严格的设计讨论。逻辑删除的数据本身作为删除了的数据来说,不应该被业务逻辑中查询到(潜规则)。
加了逻辑删除之后,并且身份证号或者手机等字段加了唯一索引之后。这种情况的话在进行业务操作的时候,被逻辑删除的数据就要被我们业务代码查询出来了。比如我一个账号(手机号)已经被删除(逻辑)了,再次注册的话,直接报错就会因为有唯一索引而保存失败。因为已经物理删除的业务数据里面含有唯一索引的字段,重新走正常新增流程的时候时候就要考虑到这种情况。
除非已经被删除的数据,唯一索引的值不会再次从新增业务,这种场景还是可以加的。只是我很少遇到这种情况
二、使用物理删除、并加唯一索引
大多数的业务场景,都不会要求物理删除,并且有写字段的值有唯一性,比如账号的身份证,用户名、手机号等。如果我们这边表的数据状态比较多,并且业务比较复杂,和其他系统关联程度比较多。涉及新增编辑的业务非常多、数量量还非常大。这种情况就使用物理删除身份证加唯一索引。
为什么呢?
说一下我们公司的案例吧,现在我们公司的会员信息,有100万,这100万的数据来源口径非常多,估计得有近10个来源口径吧,口径都这么多了,维护的人就更多了,导致有些接口有并发问题,或者说是在维护数据时候又产生了脏数据。因为对于大部分公司来说,并发测试是做得不够的。所以想这种情况唯一索引就必须加上,避脏数据的产生,便于后期的数据维护。想要记录物理删除的数据,就用单独一个表记录吧。
使用逻辑删除,不加唯一索引
这种情况就适合业务简单、数据量少的情况。因为业务简单代码好控制,好判断,好维护。数据量少,就算产生了脏数据也比较容易清理。