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