Firestore：使用嵌套的單個查詢

最近我將我的數據模型從Firebase移至Firestore。我所有的代碼都在工作，但是我有一些關於我的嵌套查詢的難題來檢索一些數據。這裏是點：Firestore：使用嵌套的單個查詢

現在對於這部分我的數據模型看起來像這樣（是另一個追隨者/飼料的例子！）：

{ 
    "Users": { //Collection 
    "UserId1" : { //Document 
     "Feed" : { //Subcollection of Id of posts from users this user Follow 
     "PostId1" : { //Document 
      "timeStamp" : "SomeDate" 
     }, 
     "PostId2" : { 
      "timeStamp" : "SomeDate" 
     }, 
     "PostId3" : { 
      "timeStamp" : "SomeDate" 
     } 
     } 
     //Some data 
    } 
    }, 
    "Posts":{ //Collection 
    "PostId1":{ //Document 
     "Comments" :{ //Subcollection 
     "commentId" : { //Document 
      "authorId": "UserId1" 
      //comentsData 
     } 
     }, 
     "Likes" : { //Subcollection 
     "UserId1" : { //Document 
      "liked" : true 
     }  
     } 
    } 
    } 
}

好吧，我的問題，現在是爲檢索的職位，一個用戶的飼料，我應該在接下來的方式查詢：

從我的頻道獲取由時間戳上次X文件訂貨

feedCol(userId).orderBy(CREATION_DATE, Query.Direction.DESCENDING).limit(limit)

之後，我應該做的，從列表中檢索每個崗位的單一查詢：workoutPostCol.document(postId)
現在我每個帖子的數據，但我想拍攝的用戶名，圖片，分。。筆者，這是一個不同的Document，所以，再次我應該做的職位userSocial(userId).document(toId)
最後，並非不重要的列表中檢索每個authorId另一個單查詢等，我需要知道，如果我當前用戶已經喜歡該帖子，所以我需要做的每一個職位（再次）一個查詢和檢查，如果我的用戶id是內部posts/likes/{userId}

現在一切工作，但認爲的Firestore價格取決於數據庫調用的次數並且它不會讓我的查詢變得更簡單，我不知道我的數據模型是否適合這種數據庫，並且我應該移動到正常的SQL或者只是再次回到Firebase。

注意：我知道這一切，將是一個很多更容易移動的喜歡，飼料等的這個子集裏面我的用戶或交文件的ArrayList，但文件的限制是1MB，如果這增長很多，將來會崩潰。另一方面，Firestore不允許使用多個whereEqualTo的子文檔查詢（尚）或OR子句。

我從誰擁有尋找一個簡單的方法來存儲這種ID's關係，使joins和queries在他們Collections，使用Arraylists將是真棒問題的用戶看了很多帖子，但1MB的上限限制它很多。

希望有人能夠澄清我的想法，或者至少教會我一些新的東西，也許我的模型只是廢話，有一個簡單和最簡單的方法來做到這一點。或者，也許我的模型不適用於非sql數據庫。

謝謝大家的一切，祝你有美好的一天。

來源

2017-10-13 Francisco Durdin Garcia

不是100％確定是否完全解決了這個問題，因爲您的使用可能存在邊緣情況。但用5分鐘的快速思考，我覺得下面的問題可以解決你的問題：

你可以考慮使用類似於Instagram的模型。如果我的記憶爲我服務，他們使用的是基於events的收藏。在這個特定的上下文中，events指的是用戶採取的所有操作。所以一個comment是一個事件，like是一個事件等。

這將使它，使您將需要總共三個主要集合。

users 
-- userID1 
---- userdata (profile pic, bio etc.) 
---- postsByUser : [postID1, postID2] 
---- followedBy : [userID2, ... ] 
---- following : [userID2, ... ] 
-- userID2 
---- userdata (profile pic, bio etc.) 


posts 
-- postID1 (timestamp, so it's sortable) 
---- contents 
---- author : userID1 
---- authorPic : authorPicUrl 
---- authorPoints : 12345 
---- taggedUsers : [] 
---- comments 
------ comment1 : { copy of comment event } 
---- likes : [userID1, userID2] 
-- postID2 (timestamp) 
---- contents 
... 


events 
-- eventID1 
---- type : comment 
---- timestamp 
---- byWhom : userID 
---- toWhichPost : postID 
---- contents : comment-text 
-- eventID2 
---- type : like 
---- timestamp 
---- byWhom : userID 
---- toWhichPost : postID

對於您的用戶個人資料頁，你會質疑users。

對於這個消息餵你會質疑posts通過用戶ID的所有帖子用戶在最近一天是以下（或任何給定的時間跨度），

對於輸入活動頁面（評論/喜歡等），你將查詢events與您的用戶ID限於最近1天（或任何給定時間段）相關

最後在用戶滾動時查詢帖子/事件的下一天（或者如果在那些日子裏沒有新活動）

再一次，這只是一個快速的想法，我知道SOF的長老哈哈已經釘死這些平時，所以請原諒我SOF的其他成員，如果這個答案有缺陷:)

希望它可以幫助舊金山的習慣，

祝你好運！

來源

2017-10-24 14:03:59 johnozbay

我喜歡'events'部分，我認爲這樣也可以控制通知只發送一次。另一方面，我已經看到，我應該更多地反常化我的數據（保存用戶名和photoUrl而不僅僅是ID），用戶不會經常更改他們的名字或圖片，並且最終會比添加無限嵌套查詢在帖子，評論，喜歡...等 –

最後，我認爲，對於'飼料'我應該留在引用的每個用戶的帖子的引用列表，最終導致，只複製一次或刪除只需要一次所有的ID就會比通過大量查詢來檢索每次我關注的每個用戶的最後一個帖子都更容易，我希望檢查我的feed。 –

@FranciscoDurdinGarcia - 我建議instagram的API的原因是因爲我相信他們也設法使用'events'方法來保持它的亮度。關於保留你關注的用戶所有帖子的清單，這是一個滑坡，因爲這需要一個反向數據模型。假設你正在關注我，我發了帖子。這就要求我寫一段數據給你的用戶。除了使安全更爲複雜，規模之外，如果我有20萬個關注者，該解決方案將要求我的用戶將1個帖子寫入200k個其他用戶的個人資料中。我會根據您的估算比例選擇該部分。 – johnozbay

Firestore：使用嵌套的單個查詢

回答

相關問題