这是一个创建于 866 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
InkAndBanner 2022-07-20 17:17:57 +08:00
总改的数据不会冗余 每次现查，很少改动的数据才会冗余。如果关联的是个很重的模型，并且不做级联删除的话，那么也需要有个名称 做查询不到的时候的托底展示
|
 |
2
Jooooooooo 2022-07-20 17:21:46 +08:00
要是总是需要再查一次的话, 冗余会方便点.
|
 |
3
InDom 2022-07-20 17:23:52 +08:00
会，但如果是很表都会用到的东西，我会考虑缓存起来。
比如每个表会记录 user_id ， 但是 UserInfo 表会以 user_id 作 key 缓存到 Redis 。 每次使用时，映射到缓存去取出来合并。 |
 |
4
leeqingshui OP @InkAndBanner 嗯嗯，是的，设计上得考虑业务场景，软件很多都是定制化卖给客户，交付给客户内部人员使用，这种情况下按理说用户信息都是确定的，但实际上系统是允许用户去修改自己的姓名啥的，如果用户改了姓名那么之前的数据就不会同步更新了。
冗余不做同步，那么无需连表查询起来方便，但不同步，历史数据就会有问题，真令人纠结！ |
 |
5
jaggle 2022-07-20 17:47:49 +08:00
这种会变的字段没有冗余必要，一些外键倒是可以冗余，比如 a->b->c ，我可能会在 c 表也加上 a 表的主键
|
|
6
jaggle 2022-07-20 17:48:51 +08:00
id 做连接查询加上索引后也很快
|
|
7
leeqingshui OP @InDom 缓存的话，如果需要多做一个模糊的筛选框，可以处理嘛~
|
 |
8
wxf666 2022-07-20 18:18:01 +08:00
数据库新手求问，多大规模的表，就考虑冗余呢？
总不至于整个用户表就十几 MB ，也搞个冗余吧？估计数据库都缓存它们到内存了 |
 |
9
Suddoo 2022-07-20 18:20:18 +08:00 via iPhone
不会，只存 id
|
 |
10
Chad0000 2022-07-20 18:21:56 +08:00
还是取决于系统规模，如果使用了微服务同时两个表不在同一服务中的，建议带上冗余防止主表删除。比如订单和客户两个是分开的服务，那么订单就建议保存客户 Id 时同时保存客户名称。客户资料修改则触发事件，订单可考虑监听这个事件并更新名称或不监听问题也不大。
|
 |
11
BiChengfei 2022-07-20 19:18:12 +08:00
自己不懂、客户没反馈，就别冗余
冗余是给架构级别做性能优化的，好多瞎冗余，代码很快就臭了 |
 |
12
helone 2022-07-20 19:20:57 +08:00
不会冗余，每次并发调用服务查询，性能指标有要求做对应优化
|
 |
13
IDAEngine 2022-07-20 19:29:02 +08:00
必须冗余啊，如果不做表外键关联
|
|
14
leeqingshui OP @jaggle
@Suddoo @BiChengfei @helone @IDAEngine 看样子大家还是倾向于不冗余。 emmm ，还想请教一个问题，如果是微服务项目中，由于用户服务会单独抽离出来为一个项目，那么当其他服务遇到需要使用用户表中的一些字段时，一般会如何进行处理？ 1.在其他服务连接用户表连表查询 2.在用户服务新增一个接口，其他服务通过 RPC 或 HTTP 多调用一次，获取对应的信息 针对 2 ，举个例子，现在业务表只存用户 id 不存用户名称，需求要求支持用户名称模糊查询，那么： 1.首先在用户服务新增一个用户名称模糊查询的接口，用于获取到对应的用户信息， 2.然后在其他服务首先调用模糊查询的用户接口，在通过 IN 查询出对应的业务列表 想问下各位大哥针对这种情况是怎么处理的？ |
|
15
InkAndBanner 2022-07-21 14:10:07 +08:00
我们之前都用 2 这种方式，服务之间暴露一些接口作为能力，其他服务去调用即可，会有分布式事务的问题。
1 这个问题是个很大的问题，如果像你这么说的去做，如果数据库分开了，很难办；如果数据库没分开，破坏了“微服务”；但是如果不连表查 在应用层通过调用接口实现的话，很痛苦。 |
 |
16
FloatLost 2022-07-21 20:43:30 +08:00
我倾向于少量冗余，控制在 2 ，3 层查询之内，如果跳太多层取一个字段查有点得不偿失，不过体量大的系统也确实比较适合缓存，效果应该会更好。
|
|
17
leeqingshui OP @InkAndBanner 嗯嗯，那对微服务而言还是方式 2 好点，有时候想两全其美太难了，哈哈
|
Select Language