。

当删除某行数据的时候#xff0c;以后再次插入相同code的数据#xff0c;数据库会报错。

问题分析

如果一张表中存在唯一性约束比如一些数据中的code且数据表使用逻辑删除。

当删除某行数据的时候以后再次插入相同code的数据数据库会报错。

问题分析

在逻辑删除中数据没有被物理删除而是用一个deleted字段标记数据已被删除当查询数据时过滤掉已删除的数据。

实际上数据仍保留在数据库中。

当插入相同code的数据时数据库的唯一性约束会限制数据的插入。

PS如果使用的是mybatis-plus框架可以通过配置文件开启逻辑删除功能。

当查询数据时会在where条件自动拼接deleted。

解决方案

解决方案是多样的要基于业务和资源做权衡。

由于项目要保持逻辑删除不变数据是无价的解决方案是在有唯一性约束的表中通过新增一个delete_timestamp字段组成联合索引。

delete_timestamp默认为0在删除数据时delete_timestamp赋值。

这样当下次插入的时候数据库不再单独对code做唯一性校验而是对code和delete_timestamp组成的联合索引做唯一性校验。

由于删除后的delete_timestamp与新增的delete_timestamp必定不同所以不会再有重复插入数据的报错。

如果数据没被删除新插入相同的code时由于delete_timestamp都默认是0所以同样会正常拦截。

PS对于delete_timestamp字段的操作建议封装成公共方法。

尽量不使用外键

虽然在学习的过程中为了理想中的保持数据一致性外键会经常被提及。

但在实际业务开发过程中非必要不使用外键约束。

原因在于外键的使用可能引发一系列数据一致性的问题。

比如在表中做增删改操作时如果表字段使用了外键要同时考虑外键所在表的数据一致性问题。

这些问题会非常频繁地出现而且解决起来会大大增加业务代码的复杂度增加了维护成本和风险。

不使用外键但又有相关需求需要在一张表中存入另一张表的主键如何实现这种情况可直接通过业务代码控制在插入数据时先查询到相应的数据再插入。

当然这不可避免难以保持数据一致性但比起要保持数据一致性付出的代价在业务层处理的成本要低得多。

在数据库中建立的数据约束都应该在业务层的时候做好相关校验让错误在业务层被拦截并抛出这样做有助于数据被定位和友好提示。

数据库约束是最后一道防线。