后端如何解决假删带来的键值重复问题(部分方案)

在后台开发的时候,我们经常会碰到一些不能重复的字段,这些字段我们一般会设置 unique 唯一,毕竟仅仅通过服务端查询判断是无法保证字段实际存储唯一的,因为会存在并发问题,然后就是我们碰到的问题,当假删一条数据之后,那么这个 unique字段就会被占用,如果还想继续使用删除的字段,那么怎么办呢?

可以集思广益一下,目前个人就想到了几种常见的方案(个人能力有限,就想到几种方向)

  1. 将原来的 unique 字段内容替换成其他的(例如带时间的),标记为已删除即可,即使恢复也可以恢复,缺点是有些记录如果保存的是关联,要关联显示出来的字段就是更新后的,由于内容变了,可能会懵逼;当然很多牺牲空间换时间的优化操作会保存一个历史值,无论维不维护这个值,都不影响结果显示,这个很常见
  2. 使用复合约束功能 unique即可,typeorm @Unique([])prisma则是@@unique([]),通过这个属性和删除标记复合,这样标记删除后,他们的 unique结果就变了,这样新创建或者更新的就可以用这个值了,这也是比较常用的手段,缺陷是要是恢复取消假删,得重新改成新的值才行,如果再删除一个同样的值,那么删除的会重复,实际上可以把假删的类型设置为数值而不是布尔,删除后可以通过自增解决(嫌麻烦可以再添加一个复合字段,默认为一个值,删除后传入一个时间戳也行),这个好处是没有优化历史记录的情况下,需要查看历史记录的时候,仍然可以看到最原始的结果
  3. 将删除的内容迁移到另外一张表中,无论是查询、还原等操作,都可以做到,并且不冲突,由于部分业务不知道这条数据删没删,如果具备历史记录功能,没有保存实际数据的可能拿不到,那么需要自行调整查询实现方案或者调整业务
  4. 碰到一些没有保存比较的表格(即使作为历史记录也基本不建立关联的那种),数据价值不大,直接真删(必要时备份到另外一张表,这样和3一样了),问题很小
  5. 数据库不设置 unique,服务端通过加锁等方式查询未删除的是否重复,不重复就创建,重复就不创建,效率个人感觉较低,一般很少这么做吧,不太好控制,关键是慢,尤其是分布锁更慢(当然对于单个服务器这个看自己,一个表在多个数据库据库这种不太了解,没碰到过,可能使用类似的分布锁等解决吧,没碰到过)
  6. 跟上面一种类似,不过乐观式写法,不写 unique,仅仅通过服务器调用查询判断是否存在而创建,这种也不是不行,要针对于人比较少,基本上不能同时操作的,那么就没事,或者即使重复了,也是小概率的问题,这个不在考虑范围之内,某种情况下也算一种解法,效率还高,毕竟适合的就是最好的

大家还有什么好手段么,想到什么可以讨论一下,毕竟个人感觉自己比较菜的,需要互相学习,这不才算是刚开始😂,当然这篇文章可能也是一个开始😂

相关推荐
南城花随雪。11 分钟前
硬盘(HDD)与固态硬盘(SSD)详细解读
数据库
儿时可乖了12 分钟前
使用 Java 操作 SQLite 数据库
java·数据库·sqlite
懒是一种态度14 分钟前
Golang 调用 mongodb 的函数
数据库·mongodb·golang
天海华兮16 分钟前
mysql 去重 补全 取出重复 变量 函数 和存储过程
数据库·mysql
gma9991 小时前
Etcd 框架
数据库·etcd
爱吃青椒不爱吃西红柿‍️1 小时前
华为ASP与CSP是什么?
服务器·前端·数据库
Yz98762 小时前
hive的存储格式
大数据·数据库·数据仓库·hive·hadoop·数据库开发
苏-言2 小时前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
Ljw...2 小时前
索引(MySQL)
数据库·mysql·索引
菠萝咕噜肉i2 小时前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁