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