我將Firebase實時數據庫用于我的測試社交網絡應用程序，您可以在其中跟蹤和接收所關注的人的信息。傳統的社交網絡。我的數據庫結構如下：Users--USER_ID_1----name----email--USER_ID_2----name----emailPosts--POST_ID_1----image----userid----date--POST_ID_2----image----userid----dateTimeline--User_ID_1----POST_ID_2------date----POST_ID_1------date我還有另一個節點“ Content”，其中僅包含所有用戶帖子的ID。因此，如果“ A”跟在“ B”之后，那么B的所有帖子ID都會添加到A的時間軸中。如果B發布了一些內容，那么它也會被添加到其所有關注者的時間表中?，F在這是我的實時數據庫解決方案，但顯然存在一些可伸縮性問題如果某人擁有10,000個關注者，而在10,000個關注者的時間軸中添加了新帖子。如果某人發布的帖子數量超過每個新關注者在其時間軸中收到的所有帖子。這些是一些問題?，F在，我正在考慮將整個事情轉移到Firestore上，因為它被稱為“可伸縮”。因此，我應該如何構建數據庫的結構，以便可以在Firestore中消除我在實時數據庫中遇到的問題。
3 回答
ABOUTYOU
TA貢獻1812條經驗 獲得超5個贊
有兩種情況
您應用中的用戶只有少數關注者。
您應用中的用戶擁有大量關注者。如果我們要將整個關注者存儲在Firestore中的單個文檔中的單個數組中。然后它將達到每個文檔1 MiB的存儲限制。
在第一種情況下，每個用戶都必須保留一個文檔，該文檔將關注者列表存儲在單個數組中的單個文檔中。通過使用arrayUnion()和arrayRemove()，可以有效地管理關注者列表。而且，當您要在時間軸中發布內容時，必須在發布文檔中添加關注者列表。
并使用下面給出的查詢來獲取帖子
postCollectionRef.whereArrayContains("followers", userUid).orderBy("date");
在第二種情況下，您只需要根據關注者數組的大小或數量來中斷用戶關注文檔。在將數組的大小達到固定大小后，下一個關注者的ID必須添加到下一個文檔中。并且第一個文檔必須保留字段“ hasNext”，該字段存儲布爾值。添加新帖子時，您必須復制帖子文檔，并且每個文檔都包含較早中斷的關注者列表。我們可以進行與上面給出的相同的查詢來獲取文檔。
添加回答
舉報
0/150
提交
取消