Question

随着最近引入的小组子集合查询，我很好奇我是否可以针对具有追随者和帖子的社交平台提出这个架构问题。

作为免责声明，我完全赞成使用云功能来使数据保持同步等方式来重复数据。

两个基于关注者的模式（一个简单的用户A跟着B，有时需要从所有关注者中拉出所有帖子）架构是：

仅搜索您对查看关注者/关注对象感兴趣的用户，它们将是文档中具有其名称的集合。

用户A跟随用户B：获得所有用户A关注= 获取用户A的关注子集合

获取所有用户A关注者= 获取用户A的子集合关注者（用户B将在那里）

Follows (C)
       ---> UID (D)
           ---> Followers (C)
             ---> UIDB (D)
             ---> UIDE (D)
           ---> Following (C)
             ---> UIDF (D)
             ---> UIDG (D)
       ---> UID (D)
           ---> Followers (C)
             ---> UIDB (D)
             ---> UIDE (D)
           ---> Following (C)
             ---> UIDF (D)
             ---> UIDG (D)

搜索用户所在的所有名为“ **关注”的收藏集

用户A跟随用户B：在用户A的关注下，我找到了用户B

优点：仅存储以下内容缺点：遍历所有子集合以获取数据

Users (Coll)

     ---> UID (Doc)
         ---> Following (C)
             ---> UIDB (D)
             ---> UIDC (D)

     ---> UID (D)
         ---> Following (C)
             ---> UIDB (D)
             ---> UIDE (D)

子集合查询使您可以在任何有该名称的文档的集合中进行查询，因此，如果我搜索：以下用户包含UIDB的所有用户，我应该只获取相关文档。

这两者似乎都是合乎逻辑的，并且可以做所需的事情，我很好奇这两个因素是否可能出于任何原因

哪个是更好的社交Firestore模式？

0 个答案: