2016-10-22 63 views
0

数据库层次结构:如何正确查询用户创建的所有帖子?

posts 
    post1_uid 
     author: user2UID 
     info1 
     info2 
    post2_uid 
     author: user1UID 
     info1 
     info2 
users 
    user1_UID 
     info1 
     info2 
     info3 
    user2_UID 
     info1 
     info2 
     info3 

状况:

用户可以创建的帖子。每个帖子都有一个“作者”属性,用于保存创建帖子的用户的UID。

如果我想告诉所有的帖子从一个用户,我写在我的火力地堡GET请求:


CODE:

if (childData.author == firebase().auth().currentUser.uid) { 
    //Show those posts created by the current user 
} 

问题

这会有效吗nt如果我的Firebase数据库拥有数百万个帖子,并且当前用户的ID需要与每个帖子的“作者”属性进行比较?

如果否,是否有更好的选择?


我的尝试

在我的“用户/ UID /”路径创建其中包含用户创建的所有职位的UID一个“上岗”节点。与迭代通过数据库上的所有帖子(百万)相比,我遍历了一个更小的json树(仅由用户创建的所有帖子(100)),以找到已由用户。但这是否真的影响性能?数据嵌套的增加值得吗?


其他数据库层次结构:

posts 
    post1_uid 
     author: user1UID 
     info1 
     info2 
    post2_uid 
     author: user1UID 
     info1 
     info2 
users 
    user1_UID 
     info1 
     info2 
     info3 
     posts 
     referenceUID 
      post1UID 
      post2UID  
    user2_UID 
     info1 
     info2 
     info3 

下面是实际的数据库层次与一些假的数据来模仿我的榜样的行为。

enter image description here


TL; DR:

如何正确地组织火力地堡数据库来优化查询寻找由用户创建的所有帖子?

回答

2

答案将无疑地嵌套在每个用户的帖子数据。

这是您从整个发布节点进行过滤时的主要性能问题。首先,为了过滤你当前用户的帖子,你必须像你注意到的那样运行这样的查询postsRef.orderByChild('author').equalTo(currentUser.uid)即使你在author上使用索引,orderByChild也是昂贵的操作,那么对于百万条记录来说这将是昂贵的。

第二种方法的缺点是,您正在复制帖子条目,但对于nosql数据库来说没关系,每次发生某些更改时更新所有副本时都必须小心。