关联查询效率，与数据冗余如何权衡

[lrgeory]

类似社交，用户的一些信息，比如头像，昵称等，是关联查询user表取信息好，还是多存一份，大量的动态，评论等冗余好
另外关联查询效率很低吗？

[yn_leopard]

觉得你应该考虑的是对象（数据）之间的关系，而不是考虑查询效率。
一般现在的服务器硬件支撑已足够优秀，软件设计时考虑的是可实现和可维护性。除非你代码写的非常乱，否则查询效率会很低吗？

[鸣鸣Amadues]

数据尽量不要多存一份，不然维护和同步很麻烦。 联合查询不麻烦，效率也不会低。 主要还是实体要设计好，优先考虑事物关系，而不是怎么样查询方便或者更新方便。

[maradona1984]

项目简单,关联查询
项目复杂多变,数据拼接调用具体的服务,不然就是泥潭,牵一发动全身

[鸣鸣Amadues]

引用 4 楼 Geory王 的回复:

[quote=引用 2 楼 鸣鸣Amadues 的回复:] 数据尽量不要多存一份，不然维护和同步很麻烦。 联合查询不麻烦，效率也不会低。 主要还是实体要设计好，优先考虑事物关系，而不是怎么样查询方便或者更新方便。

类似你推荐的博客与用户之间的冗余数据，一旦作者昵称更改，所有博客里的昵称信息务必需要全部更新， 类似我的社交产品，涉及到的昵称，头像，可能在动态表，评论表，回复表，赞表，收藏表都会冗余这些字段。一但用户信息修改，就需要大量更新全部历史数据，这样的话你觉得建议关联，还是冗余[/quote] 历史数据需要不需要更新是看需求的，我见过有些论坛是不会更新的，新帖子的用户名用最新的，老帖子还是老的用户名不更改；如果你需要做同步更新，在查询和维护之间必然要做一些取舍。 我对这类问题的看法是，以业务为基准，业务含义具有唯一性，所以也就是所有数据只存一份，在查询性能明显受到影响性时，再考虑多存一份便于查询，这一份数据相当于缓存，有缓存就要做同步，这个同步可以在后台定时定期执行，具体看实际情况。

[lrgeory]

引用 2 楼 鸣鸣Amadues 的回复:

数据尽量不要多存一份，不然维护和同步很麻烦。
联合查询不麻烦，效率也不会低。
主要还是实体要设计好，优先考虑事物关系，而不是怎么样查询方便或者更新方便。

类似你推荐的博客与用户之间的冗余数据，一旦作者昵称更改，所有博客里的昵称信息务必需要全部更新，
类似我的社交产品，涉及到的昵称，头像，可能在动态表，评论表，回复表，赞表，收藏表都会冗余这些字段。一但用户信息修改，就需要大量更新全部历史数据，这样的话你觉得建议关联，还是冗余

[nayi_224]

有意识的数据冗余可能会让你的一个查询变得简单，但是会增加整个模块的复杂度，以后扩展、维护的时候更麻烦 在合理的查询优化下，关联查询的效率不低 功能实在太复杂，或者数据量过大，又对效率有苛刻要求，可以考虑冗余。但是也要保证冗余量尽量少。

[stacksoverflow]

这种场景最适合用mongodb了。

[HinanaiTenshi]

这个问题的关键在于你当前面临的场景最大的痛点是什么？ 冗余字段的好处是便于做数据分析，不冗余的好处是数据模型修改成本低。 另外，就算不做冗余，头像、昵称什么的非核心数据也没必要放到用户核心表去