@lmshl
@xaplux 好的，感谢回复，我去了解下~

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

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

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

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

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

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

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

@InkAndBanner 嗯嗯，是的，设计上得考虑业务场景，软件很多都是定制化卖给客户，交付给客户内部人员使用，这种情况下按理说用户信息都是确定的，但实际上系统是允许用户去修改自己的姓名啥的，如果用户改了姓名那么之前的数据就不会同步更新了。
冗余不做同步，那么无需连表查询起来方便，但不同步，历史数据就会有问题，真令人纠结！

typora （本地） + hexo （网页） + minio （图片存储）

@nothingistrue 哈哈，老哥说的也有道理，我有时候写代码有点强迫症了~

@alen0206 嗯嗯，这个问题应该是主要兼容前端去考虑，返回新增或更新后的实体这个在部分场景前端确实需要，比如前端准备新增或更新数据前端会需要一个对话框表单，若点击保存调后端接口后弹框不关闭（此对话框又属于另一个对话框里的一部分），那么确实需要返回实体给前端；
true or false 前端一般是直接判断后端状态码是否等于 200 ，不会进一步去看这个字段值，一般新增出错 都会抛出异常 给前端提示了，似乎没多大意义。
nice~