Firestore 社交媒體好友請求數據 model

Question

我正在使用 Firestore 構建社交媒體應用程序，我想知道為好友請求構建數據的最佳方式是什么。

當用戶 John 想要加好友請求 Mary 和 Anne 時，我是否創建一個名為friend_requests的根集合並添加 3 個文檔：

1. 一個以 John 的userId為鍵的文檔，其值將是一個 object，每個 Mary 和 Anne 都包含他們的userId和請求status （待定/接受/拒絕）
2. 一個以 Mary 的userId作為鍵的文檔和一個包含 object 的數組，其中包含 John 的userId和請求status
3. 一個以 Annes 的userId作為鍵的文檔和一個包含 object 的數組，其中包含 John 的userId和請求status

現在，當 Anne 和 Mary 接受好友請求時，我刪除了friend_requests集合中的所有三個文檔，然后：

• 我為每個用戶（在users根集合中）添加了一個名為friends的子集合，其中包含已接受請求的朋友的 usersIds、displayNames 和 photoURLs

或者

• 我應該為每個用戶創建另一個包含朋友信息的文檔的根集合friends嗎？

似乎有很多重復的數據，所以我試圖圍繞它尋找最好和最有效的方法來在 Firestore 中完成它。 任何建議將不勝感激，也許我走錯了路！

Answer 1

雖然 Dharmaraj 的解決方案肯定會奏效，但我認為還有一個更簡單的解決方案，可以幫助您稍微減少讀取次數。 所以我們假設userOne向userOne發送好友請求，而userThree向userTwo發送好友請求。

Firestore-root
  |
  --- users (collection)
  |    |
  |    --- $userOneUid (document)
  |    |     |
  |    |     --- //User data
  |    |
  |    --- $userTwoUid (document)
  |    |     |
  |    |     --- //User data
  |    |
  |    --- $userThreeUid (document)
  |          |
  |          --- //User data
  |
  --- requests (collection)
       |
       --- $userOneUid (document)
       |     |
       |     --- ownRequests (map)
       |     |      |
       |     |      --- $userTwoUid
       |     |             |
       |     |             --- displayName: "User Two"
       |     |             |
       |     |             --- photoUrl: "https://"
       |     |             |
       |     |             --- status: "requested"
       |     |
       |     --- friendRequests (map)
       |     |      |
       |     |      --- $userThreeUid
       |     |             |
       |     |             --- displayName: "User Three"
       |     |             |
       |     |             --- photoUrl: "https://"
       |     |             |
       |     |             --- status: "requested"
       |     |
       |     --- allFriends (map)
       |            |
       |            --- //All friends
       |
       --- $userTwoUid (document)
       |     |
       |     --- friendRequests (map)
       |            |
       |            --- $userOneUid
       |                   |
       |                   --- displayName: "User One"
       |                   |
       |                   --- photoUrl: "https://"
       |                   |
       |                   --- status: "requested"
       |
       --- $userThreeUid (document)
             |
             --- ownRequests (map)
                    |
                    --- $userOneUid
                           |
                           --- displayName: "User One"
                           |
                           --- photoUrl: "https://"
                           |
                           --- status: "requested"

為了有一個扁平化的模式，我沒有在用戶 object 下創建嵌套 collections 或嵌套映射，而是創建了一個名為requests的單獨頂級集合。 在這個集合中，將有管理用戶自己的請求、好友請求和所有好友的文檔。

看到這個架構，你可能會想，哦，但是我怎么能設法在一個文檔中添加這么多的數據呢？ 即使我們被限制在單個文檔中存儲最多 1 Mib 的存儲空間，當涉及到存儲這些簡單對象時，我們也可以存儲很多。 但是，如果您擔心空間，那么您應該考慮為每種情況創建單獨的 collections， ownRequests ， friendRequests和allFriends 。 在這種情況下，為簡單起見，我們假設所有數據都適合單個文檔。

展望未來，如您所見，我們在每個 map 下存儲了來自用戶 object 的最小數據，其中鍵是 UID，值由三個字段表示。 通過這種方式，您可以顯示姓名和頭像，以清楚地表明執行好友請求的用戶。

現在，當userOne向userTwo發送好友請求時，需要進行兩個操作。 第一個是在userTwo 的friendRequests userTwo中添加userOne ，第二個是在自己的ownRequests userTwo下添加userTwo。

在這兩個朋友之間，我們現在有一個朋友請求，這意味着您必須始終確保限制userTwo向userOne發送朋友請求。 你怎么能那樣做？ 只需檢查ownRequests的 ownRequests 中是否存在$userTwoUid userOne 。 如果希望userOne能夠取消好友請求，或者userTwo拒絕好友請求，那么只需將上述兩個操作還原即可。

同樣的規則適用於userThree的情況。

關於顯示數據，如果要顯示自己的請求列表、好友請求列表或所有好友列表，則需要進行一次數據庫調用，這需要一次讀取。 但是，如果您需要加載用戶的更多數據，那么當您單擊該用戶時，您可以執行另一個請求並加載該用戶的所有數據，因為您已經知道 UID。

當userTwo接受來自userOne的好友請求時，只需將他們的對象移動到allFriends map 中。 您也可以提前bannerFriends並添加橫幅好友，以防止其他用戶發送好友請求。 另請注意，這也將只花費一次閱讀。

似乎有很多重復的數據，所以我試圖圍繞它尋找最好和最有效的方法來在 Firestore 中完成它。

對於像 Firestore 這樣的 NoSQL 數據庫，非規范化數據是一種非常常見的做法，為此我建議您查看以下帖子中的答案：

• Firebase Cloud Firestore 中的非規范化是什么？

您還可以在其中看到構建此類數據庫的其他解決方案。

Answer 2

第一種方法似乎有很多文檔創建和刪除。 相反，您可以在“用戶”下創建一個子集合“朋友”並存儲一個字段“狀態”。 所以結構將是：

users -> {userId} -> friends -> {friendId}

當 User2 向 User1 發送好友請求時，您可以在 User1 下添加好友子文檔，並將status字段與friendId一起設置為requested 。 一旦 User1 接受請求，只需將狀態更新為active 。 這將減少每個好友請求的 1 次刪除和 1 次創建操作的成本。

這應該涵蓋許多用例，包括：

1. 列出用戶的好友/好友請求
2. 列出我發送的待處理好友請求（如果您使用子收藏，可以使用收藏組查詢）

如果您需要在接受好友請求后處理更新數據庫、發送通知/電子郵件等任何事情，您可以使用Cloud Functions 的 Firestore 觸發器。

---

friends子集合可以是根級集合，但在這種情況下，您必須添加另一個字段userId來過濾給定用戶的朋友。 這並沒有太大的區別，但結帳在 Firestore 中使用根集合與子集合有什么好處？ 了解更多信息。