search

wolfogre / blog-utterances

utterances of my blog.
5 stars 0 forks source link

软删除之痛 #44

Open wolfogre opened 5 years ago

wolfogre commented 5 years ago

https://blog.wolfogre.com/posts/trap-of-soft-delete/

alswl commented 4 years ago

文章不错，如果能够给一些指导方针，讲一讲什么场景下推荐使用软删除/硬删除；使用软删除如何避免上述问题那就更好了。

bluntdel commented 4 years ago

确实列出了软删除的不少痛苦场景，尤其是对唯一索引的影响。这里有一种方案是将删除标识置为自增的多值，例如第一次删除为1，第二次为2。

frankcai4real commented 4 years ago

nice

razertory commented 4 years ago

直接维护一个 deleted 字段类型和 primary key 一样默认为 0，让这个字段在 soft-delete 的时候，更新为 Primary Key 的值就 OK 了

snowdream commented 4 years ago

看起来确实有问题，有什么解决办法吗？

wuranxu commented 3 years ago

写的很棒！

myhyh commented 3 years ago

如果假设软删除的数据不会被再次更新,定期把modify_time很古老的已删除数据dump出去,然后从表里真的删掉应该也能解决问题吧

lnnt commented 1 year ago

现在使用unix时间戳标记删除不需要改造gorm了 见Delete-Flag

renzhengzhang commented 3 weeks ago

MySQL 8 可以在唯一索引中使用表达式来解决与逻辑删除的冲突。

例如 user 表中要求未被删除的 username 字段唯一

alter table user add unique index uk_deleted_username ((if(deleted = 0, username, null)));