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

想问下大家在设计数据库表的时候,是否会对用户名称这类字段进行冗余处理?

  •  
  •   leeqingshui · 134 天前 · 1000 次点击
    这是一个创建于 134 天前的主题,其中的信息可能已经有所发展或是发生改变。
    17 条回复    2022-07-22 07:58:45 +08:00
    InkAndBanner
        1
    InkAndBanner  
       134 天前
    总改的数据不会冗余 每次现查,很少改动的数据才会冗余。如果关联的是个很重的模型,并且不做级联删除的话,那么也需要有个名称 做查询不到的时候的托底展示
    Jooooooooo
        2
    Jooooooooo  
       134 天前
    要是总是需要再查一次的话, 冗余会方便点.
    InDom
        3
    InDom  
       134 天前
    会,但如果是很表都会用到的东西,我会考虑缓存起来。

    比如每个表会记录 user_id , 但是 UserInfo 表会以 user_id 作 key 缓存到 Redis 。

    每次使用时,映射到缓存去取出来合并。
    leeqingshui
        4
    leeqingshui  
    OP
       134 天前
    @InkAndBanner 嗯嗯,是的,设计上得考虑业务场景,软件很多都是定制化卖给客户,交付给客户内部人员使用,这种情况下按理说用户信息都是确定的,但实际上系统是允许用户去修改自己的姓名啥的,如果用户改了姓名那么之前的数据就不会同步更新了。
    冗余不做同步,那么无需连表查询起来方便,但不同步,历史数据就会有问题,真令人纠结!
    jaggle
        5
    jaggle  
       134 天前
    这种会变的字段没有冗余必要,一些外键倒是可以冗余,比如 a->b->c ,我可能会在 c 表也加上 a 表的主键
    jaggle
        6
    jaggle  
       134 天前
    id 做连接查询加上索引后也很快
    leeqingshui
        7
    leeqingshui  
    OP
       134 天前
    @InDom 缓存的话,如果需要多做一个模糊的筛选框,可以处理嘛~
    wxf666
        8
    wxf666  
       134 天前
    数据库新手求问,多大规模的表,就考虑冗余呢?

    总不至于整个用户表就十几 MB ,也搞个冗余吧?估计数据库都缓存它们到内存了
    Suddoo
        9
    Suddoo  
       134 天前 via iPhone
    不会,只存 id
    Chad0000
        10
    Chad0000  
       134 天前
    还是取决于系统规模,如果使用了微服务同时两个表不在同一服务中的,建议带上冗余防止主表删除。比如订单和客户两个是分开的服务,那么订单就建议保存客户 Id 时同时保存客户名称。客户资料修改则触发事件,订单可考虑监听这个事件并更新名称或不监听问题也不大。
    BiChengfei
        11
    BiChengfei  
       134 天前
    自己不懂、客户没反馈,就别冗余
    冗余是给架构级别做性能优化的,好多瞎冗余,代码很快就臭了
    helone
        12
    helone  
       134 天前
    不会冗余,每次并发调用服务查询,性能指标有要求做对应优化
    IDAEngine
        13
    IDAEngine  
       134 天前
    必须冗余啊,如果不做表外键关联
    leeqingshui
        14
    leeqingshui  
    OP
       133 天前
    @jaggle
    @Suddoo
    @BiChengfei
    @helone
    @IDAEngine
    看样子大家还是倾向于不冗余。

    emmm ,还想请教一个问题,如果是微服务项目中,由于用户服务会单独抽离出来为一个项目,那么当其他服务遇到需要使用用户表中的一些字段时,一般会如何进行处理?

    1.在其他服务连接用户表连表查询
    2.在用户服务新增一个接口,其他服务通过 RPC 或 HTTP 多调用一次,获取对应的信息

    针对 2 ,举个例子,现在业务表只存用户 id 不存用户名称,需求要求支持用户名称模糊查询,那么:
    1.首先在用户服务新增一个用户名称模糊查询的接口,用于获取到对应的用户信息,
    2.然后在其他服务首先调用模糊查询的用户接口,在通过 IN 查询出对应的业务列表

    想问下各位大哥针对这种情况是怎么处理的?
    InkAndBanner
        15
    InkAndBanner  
       133 天前
    我们之前都用 2 这种方式,服务之间暴露一些接口作为能力,其他服务去调用即可,会有分布式事务的问题。
    1 这个问题是个很大的问题,如果像你这么说的去做,如果数据库分开了,很难办;如果数据库没分开,破坏了“微服务”;但是如果不连表查 在应用层通过调用接口实现的话,很痛苦。
    FloatLost
        16
    FloatLost  
       133 天前
    我倾向于少量冗余,控制在 2 ,3 层查询之内,如果跳太多层取一个字段查有点得不偿失,不过体量大的系统也确实比较适合缓存,效果应该会更好。
    leeqingshui
        17
    leeqingshui  
    OP
       132 天前
    @InkAndBanner 嗯嗯,那对微服务而言还是方式 2 好点,有时候想两全其美太难了,哈哈
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1666 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 45ms · UTC 17:45 · PVG 01:45 · LAX 09:45 · JFK 12:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.