2016-10-22 69 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數據庫來說沒關係,每次發生某些更改時更新所有副本時都必須小心。