V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
yannxia
V2EX  ›  问与答

同事提出来的数据设计,咨询下大家

  •  1
     
  •   yannxia · 345 天前 · 1921 次点击
    这是一个创建于 345 天前的主题,其中的信息可能已经有所发展或是发生改变。

    为了脱敏,这里用一个更通用的 CASE 来说明

    我们有一个 用户表 和 产品目录表, 他们之间是 M:N 的关系,我认为这个表就 2 ~ 3 个字段,USER_ID 和 CATEGROY_ID 的外键,最多加上一个 CREATE_Time 但是我的同事认为一定加一个 DELETE_TIME,我们要知道他们什么时候解除关系的,并且可以通过这个查询历史(说是运营会分析[我认为是捏造的])。

    我认为这个设计不仅没有必要而且很扯淡,

    1. 我们对于用户和产品本身都没有存历史记录,这里记得关系的历史记录更是没啥卵用,糟糕的可能是产品里面还会删除,这里会出现一个破坏性的 KEY
    2. 关联的历史作为操作历史存在一个单独的表中,并且对于 OLTP 系统不适合做分析,找个 OLAP 的系统抓快照岂不是更好?

    最终会议不欢而散,大家一般平时怎么处理这个问题。

    PS:我认为包括在业务数据里加一个 Deleted 字段都是偷懒的行为,增加一个 Deleted_User 的表,将删除的数据移动一下可能会更合理点。

    第 1 条附言  ·  343 天前
    大家在回答之前还是先想一下,保留主体的历史数据 & 保留关联的历史数据 是完全不一样的意义。

    保留关联关系的历史完全只有一种含义,某个对象在历史上和某个东西链接,连接端的两侧的修改都是无法追溯的。
    保留主体的历史数据,至少我能至少知道在删除之前他是什么样的。
    22 条回复    2020-12-28 10:05:43 +08:00
    bsg1992
        1
    bsg1992  
       345 天前
    业务表加 Deleted 字段很正常,用于软删除。你那个同事都说了 运营会要统计。你为什么会人为是捏造的呢
    georgetso
        2
    georgetso  
       345 天前
    重要业务数据用软删除的确比较普遍.
    yannxia
        3
    yannxia  
    OP
       345 天前
    @bsg1992 因为我问了运营,人家不需要现在~
    baleeny
        4
    baleeny  
       345 天前
    我也很烦软删除。。。。写 sql 语句很烦。。
    dddz97
        5
    dddz97  
       345 天前
    按楼主所说的话,确实没必要有 deleted,删除了放删除表里不是更好
    nuistzhou
        6
    nuistzhou  
       345 天前 via iPhone
    现在不需要不代表以后不需要,最好还是叫你同事还有运营的人坐下来,一起决定,不然万一以后人改变主意又要这个字段的话,你可就是背锅侠了...
    naoh1000
        7
    naoh1000  
       345 天前 via iPhone
    删除一点表的话以后改字段要改两张表的麻烦
    naoh1000
        8
    naoh1000  
       345 天前 via iPhone
    @naoh1000 typo: 删除一点表=>删除用户放单独一张表
    renmu123
        9
    renmu123  
       345 天前 via Android
    运营也说了目前不要,之后如果要那你就会背锅了。其实可以加个 updatetime 来替代 deletetime,可能会更加通用一点。(虽然我本人也不赞同,但是要向产品妥协)
    NerverLibis
        10
    NerverLibis  
       345 天前 via iPhone
    解除关系的操作时间,可以通过日志统计,如果想在后台显示,加在 redis 里便是
    swulling
        11
    swulling  
       345 天前 via iPhone
    能不用软删除就不用,逻辑复杂起来一团乱。

    如果有这个需求,专门建一个 deleted 表反而成本最低,如过只是想查看记录或者捞回,写到专门的操作日志里也就行了
    wysnylc
        12
    wysnylc  
       345 天前
    他现在说不要不代表以后不要,为什么大家都知道数据不要 delete 而是 update status?
    经验都是血与泪的教训换来的,人家给你分享是让你少踩坑,你头铁喜欢交学费是你的事
    dswyzx
        13
    dswyzx  
       345 天前
    运营动嘴一个需求,你没有冗余设计那就是大改大动.
    所以说嘛,为啥要过度设计,有需求报工期排班搞嘛.说不定还有加班费
    但有的公司就规定要软删除,尤其是这么一众不能注销的企业,啥数据都要存着
    Cbdy
        14
    Cbdy  
       345 天前 via Android
    我支持 LZ 的设计,设计这种所谓的“软删除”是愚蠢的做法,过度设计而且莫名其妙
    c6h6benzene
        15
    c6h6benzene  
       345 天前 via iPhone
    缓慢变化维度,要么你加个 begin date/end date 也行啊。
    akira
        16
    akira  
       345 天前   ❤️ 1
    关联关系表的变化 放在操作记录表去做记录会更好
    用户表 和 产品目录表 这类表做软删除是个好习惯

    按你的想法,关联关系变化不记录,数据删除是硬删除。万一哪天有人操作失误删除错了数据,你打算怎么恢复数据
    liuxey
        17
    liuxey  
       345 天前
    软删除 软的是数据主体而不是“关系”,“关系”不需要软删除,如果要查什么时候解除关系的,用日志啊!
    johnsona
        18
    johnsona  
       345 天前 via iPhone
    让他来写,不就好了
    zppass
        19
    zppass  
       344 天前
    数据现在一般都不会硬删除,标记一下,
    想统计的话除了最后的更改时间,可以单独加个表记录或者搞个账户日志,注册,解绑,账户升级
    数据造假注水还整不过来呢,怎么可能直接删呢
    yannxia
        20
    yannxia  
    OP
       343 天前
    @akira 保留管理关系的历史本身就是有问题的,因为 产品目录会一直一直修改 [删除是软删除] ,保留历史的关系其实意义不大,你也不知道那个时刻的产品目录是什么。

    我只是不倾向加这种只有一点点信息量的 Delete_at,还不如搞操作表或者是快照
    yannxia
        21
    yannxia  
    OP
       343 天前
    @wysnylc 写了 6/7 年的代码,几乎没保留过历史的关联关系,血和泪的教训我为什么一次没遇见?
    wysnylc
        22
    wysnylc  
       342 天前
    良言难劝该死鬼,慈悲不度自绝人
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   920 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 20:33 · PVG 04:33 · LAX 12:33 · JFK 15:33
    ♥ Do have faith in what you're doing.