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

总改的数据不会冗余 每次现查，很少改动的数据才会冗余。如果关联的是个很重的模型，并且不做级联删除的话，那么也需要有个名称 做查询不到的时候的托底展示

要是总是需要再查一次的话, 冗余会方便点.

会，但如果是很表都会用到的东西，我会考虑缓存起来。

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

每次使用时，映射到缓存去取出来合并。

这种会变的字段没有冗余必要，一些外键倒是可以冗余，比如 a->b->c ，我可能会在 c 表也加上 a 表的主键

id 做连接查询加上索引后也很快

@InDom 缓存的话，如果需要多做一个模糊的筛选框，可以处理嘛~

数据库新手求问，多大规模的表，就考虑冗余呢？

总不至于整个用户表就十几 MB ，也搞个冗余吧？估计数据库都缓存它们到内存了

不会，只存 id

还是取决于系统规模，如果使用了微服务同时两个表不在同一服务中的，建议带上冗余防止主表删除。比如订单和客户两个是分开的服务，那么订单就建议保存客户 Id 时同时保存客户名称。客户资料修改则触发事件，订单可考虑监听这个事件并更新名称或不监听问题也不大。

自己不懂、客户没反馈，就别冗余
冗余是给架构级别做性能优化的，好多瞎冗余，代码很快就臭了

不会冗余，每次并发调用服务查询，性能指标有要求做对应优化

必须冗余啊，如果不做表外键关联

@jaggle
@Suddoo
@BiChengfei
@helone
@IDAEngine
看样子大家还是倾向于不冗余。

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

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

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

想问下各位大哥针对这种情况是怎么处理的？

我们之前都用 2 这种方式，服务之间暴露一些接口作为能力，其他服务去调用即可，会有分布式事务的问题。
1 这个问题是个很大的问题，如果像你这么说的去做，如果数据库分开了，很难办；如果数据库没分开，破坏了“微服务”；但是如果不连表查 在应用层通过调用接口实现的话，很痛苦。

我倾向于少量冗余，控制在 2 ，3 层查询之内，如果跳太多层取一个字段查有点得不偿失，不过体量大的系统也确实比较适合缓存，效果应该会更好。

@InkAndBanner 嗯嗯，那对微服务而言还是方式 2 好点，有时候想两全其美太难了，哈哈