
为了脱敏,这里用一个更通用的 CASE 来说明
我们有一个 用户表 和 产品目录表, 他们之间是 M:N 的关系,我认为这个表就 2 ~ 3 个字段,USER_ID 和 CATEGROY_ID 的外键,最多加上一个 CREATE_Time 但是我的同事认为一定加一个 DELETE_TIME,我们要知道他们什么时候解除关系的,并且可以通过这个查询历史(说是运营会分析[我认为是捏造的])。
我认为这个设计不仅没有必要而且很扯淡,
最终会议不欢而散,大家一般平时怎么处理这个问题。
PS:我认为包括在业务数据里加一个 Deleted 字段都是偷懒的行为,增加一个 Deleted_User 的表,将删除的数据移动一下可能会更合理点。
1 bsg1992 2020 年 12 月 25 日 业务表加 Deleted 字段很正常,用于软删除。你那个同事都说了 运营会要统计。你为什么会人为是捏造的呢 |
2 georgetso 2020 年 12 月 25 日 重要业务数据用软删除的确比较普遍. |
4 baleeny 2020 年 12 月 25 日 我也很烦软删除。。。。写 sql 语句很烦。。 |
5 dddz97 2020 年 12 月 25 日 按楼主所说的话,确实没必要有 deleted,删除了放删除表里不是更好 |
6 flgn88 2020 年 12 月 25 日 via iPhone 现在不需要不代表以后不需要,最好还是叫你同事还有运营的人坐下来,一起决定,不然万一以后人改变主意又要这个字段的话,你可就是背锅侠了... |
7 naoh1000 2020 年 12 月 25 日 via iPhone 删除一点表的话以后改字段要改两张表的麻烦 |
9 renmu123 2020 年 12 月 25 日 via Android 运营也说了目前不要,之后如果要那你就会背锅了。其实可以加个 updatetime 来替代 deletetime,可能会更加通用一点。(虽然我本人也不赞同,但是要向产品妥协) |
10 NerverLibis 2020 年 12 月 25 日 via iPhone 解除关系的操作时间,可以通过日志统计,如果想在后台显示,加在 redis 里便是 |
11 swulling 2020 年 12 月 25 日 via iPhone 能不用软删除就不用,逻辑复杂起来一团乱。 如果有这个需求,专门建一个 deleted 表反而成本最低,如过只是想查看记录或者捞回,写到专门的操作日志里也就行了 |
12 wysnylc 2020 年 12 月 25 日 他现在说不要不代表以后不要,为什么大家都知道数据不要 delete 而是 update status? 经验都是血与泪的教训换来的,人家给你分享是让你少踩坑,你头铁喜欢交学费是你的事 |
13 dswyzx 2020 年 12 月 25 日 运营动嘴一个需求,你没有冗余设计那就是大改大动. 所以说嘛,为啥要过度设计,有需求报工期排班搞嘛.说不定还有加班费 但有的公司就规定要软删除,尤其是这么一众不能注销的企业,啥数据都要存着 |
14 Cbdy 2020 年 12 月 25 日 via Android 我支持 LZ 的设计,设计这种所谓的“软删除”是愚蠢的做法,过度设计而且莫名其妙 |
15 c6h6benzene 2020 年 12 月 25 日 via iPhone 缓慢变化维度,要么你加个 begin date/end date 也行啊。 |
16 akira 2020 年 12 月 25 日 关联关系表的变化 放在操作记录表去做记录会更好 用户表 和 产品目录表 这类表做软删除是个好习惯 按你的想法,关联关系变化不记录,数据删除是硬删除。万一哪天有人操作失误删除错了数据,你打算怎么恢复数据 |
17 auin 2020 年 12 月 25 日 软删除 软的是数据主体而不是“关系”,“关系”不需要软删除,如果要查什么时候解除关系的,用日志啊! |
18 johnsona 2020 年 12 月 26 日 via iPhone 让他来写,不就好了 |
19 zppass 2020 年 12 月 26 日 数据现在一般都不会硬删除,标记一下, 想统计的话除了最后的更改时间,可以单独加个表记录或者搞个账户日志,注册,解绑,账户升级 数据造假注水还整不过来呢,怎么可能直接删呢 |
20 Yanickkk OP @akira 保留管理关系的历史本身就是有问题的,因为 产品目录会一直一直修改 [删除是软删除] ,保留历史的关系其实意义不大,你也不知道那个时刻的产品目录是什么。 我只是不倾向加这种只有一点点信息量的 Delete_at,还不如搞操作表或者是快照 |
22 wysnylc 2020 年 12 月 28 日 良言难劝该死鬼,慈悲不度自绝人 |