现在有两张表，A和B，A是记录用户信息的表，B是记录用户发布的文章内容的表。
我现在在B中有个字段是用来记录A中的用户名的，这样可以让我我知道B中的文章都是哪些用户发布的，但是现在遇到的问题是如果A表中的用户字段被用户自己修改了，但是B表中用户名这个字段如何才能跟着A表的修改一起同步了。
现在有一种解决方法是我在B表记录A的表用户的ID，然后每次读取B表的数据的时候去查询A表的用户信息，但是这样性能太低了，因为假设我现在在做一个文章列表需要展示用户名这个字段，那我没展示一条文章就需要去查询一次A表。
既然用了mongodb，那么就只能承担no sql带来的特性
@owen-hong 你要读列表本来就要查一次数据库，现在只是多查了一次，时间复杂度和原来是一样的。你自己权衡吧，一个是提高数据之间的藕合度，另一个是多查一次
@waksana 你的应用场景是只读取两次，实际情况如果你现在在要做一个文章列表，这个列表可能是有N个用户的文章，你每次读取这个文章列表的一条数据的时候，你都要去读B和A表的数据，如果这个文章列表要展示一千条数据，那光是这一个页面就需要去读取A和B分别各一千次，太糟了
这样你不觉得数据冗余吗？
而且我觉得mongoose的populate可能有类似的优化哟，这样你就可以直接用populate了，只用读两次数据库而已啦，别这么爱护你的服务器。。。
不同用户发的文章列表很简单啊，你只要把文章先查出来，然后把用户id收集起来，一次性查出来。
请使用 sql。
感觉到性能瓶颈了，再优化这地方，否则还是以维护性优先。 同时更新两个表，你是不是还得实现事务管理，万一失败记得回滚
@airyland 但是其实刚刚我说了，如果你现在要做一个文章列表，这个列表可能是不同用户去发布的，你可能一条数据就需要去查询一次A表，为的就是获取当前这个文章的用户名，其实我觉得最合理的方法应该是我把用户名这个字段记录在B表中，然后A表更新的时候我去把B表的数据也更新了，这样以后不管做什么查询B表做的任何操作就不需要去查A了
我觉得存id再获取id对应的信息这个方法是合理的。相当于Mongoose的populate, 数据量大时可能会查询慢。 但是用户信息完全可以用Memcache或者Redis缓存下来，这样理论上查询会比较快，但是在数据量还不大时没必要这样做。
