我正在使用 Firestore 構建社交媒體，我想知道為好友請求構建資料的最佳方式是什么。
當用戶 John 想要加好友請求 Mary 和 Anne 時，我是否創建一個名為的根集合friend_requests并添加 3 個檔案：
- 以 John's
userId為鍵的檔案，其值將是 Mary 和 Anne's 各自的物件，其中包含他們的請求userId和status請求（待定/接受/拒絕） - 一個以 Mary's
userId作為鍵的檔案和一個以 John'suserId和status請求為物件的陣列 - 以 Annes
userId為鍵的檔案和以 John 為物件的陣列userId和status請求
現在，當 Anne 和 Mary 接受好友請求時，我洗掉了集合中的所有三個檔案friend_requests，然后：
- 我為每個
users名為的用戶（在根集合中）添加了一個子集合friends，其中包含已接受請求的朋友的 usersIds、displayNames 和 photoURLs
或者
friends我應該為每個用戶創建另一個包含朋友資訊的檔案的根集合嗎？
似乎有很多重復的資料，所以我試圖繞開它，并在 Firestore 中找到最好和最有效的方法。任何建議將不勝感激，也許我走錯了路！
uj5u.com熱心網友回復：
第一種方法似乎有很多檔案創建和洗掉。相反，您可以在“用戶”下創建一個子集合“朋友”并存盤一個欄位“狀態”。所以結構將是：
users -> {userId} -> friends -> {friendId}
當 User2 向 User1 發送好友請求時，您可以在 User1 下添加好友子檔案，并將該status欄位設定為requestedwith friendId。一旦 User1 接受請求，只需將狀態更新為active. 這將減少每個好友請求的 1 次洗掉和 1 次創建操作的成本。
這應該涵蓋許多用例，包括：
- 列出用戶的好友/好友請求
- 列出我發送的待處理好友請求（如果您使用子收藏，可以使用收藏組查詢）
如果您需要在接受好友請求后處理更新資料庫、發送通知/電子郵件等任何事情，您可以使用Cloud Functions 的 Firestore 觸發器。
子集合可以是根friends級集合，但在這種情況下，您必須添加另一個欄位userId來過濾給定用戶的朋友。這并沒有太大的區別，但結帳在 Firestore 中使用根集合與子集合有什么好處？了解更多資訊。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/507494.html
標籤：Google Cloud Collective 火力基地 谷歌云火库 nosql 数据建模