在Firebase中，是否应该从主集合中分离出定期更新的帖子和用户数据收藏夹，投票...？

如何解决在Firebase中，是否应该从主集合中分离出定期更新的帖子和用户数据收藏夹，投票...？

我有一个基本的应用程序，看起来像一个博客，在Firebase中有帖子和用户数据。它使用React native，Context API状态管理和TypeScript进行编码。

用户必须能够像在帖子中一样在书签中添加帖子。

他们还有一个合作伙伴，其书签对用户可见，必须实时更新。这可以通过云功能来管理，也可以在合作伙伴可以访问的文档中重复。

帖子列表（主页）上所需的信息是标题，imageUrl，书签（对于当前用户），类别。

帖子页面上所需的信息是相同的，加上totalFavorites，liked，totalLikes，contentText，authorName，authorAvatarURL，authorTitle。

我试图了解每种结构的优缺点：

1 /整体式

userData:
  - name
  - avatarURL
  - title # for authors
  - bookmarks: 
    - postId: timestamp
    - ...
  - partnerBookmarks: 
    - postId: timestamp
    - ...
  - likes: [postId,...]

postData:
  - title
  - imageUrl
  - category
  - contentText
  - authorRef: user
  - totalLikes
  - totalFavorites

这是非常好的方法，但是有几个问题：

• 我需要确保Firestore每次添加收藏夹或类似内容时都不会传输所有userData和postData，因为这是在不更改的情况下传输的很多数据。
• 无论如何，都需要在React Native上下文中分离数据，以避免重新呈现任何东西。

2 /碎片结构

userData: userUid
  - name
  - avatarURL
  - title # for authors


bookmarks: userUid
    - postId: timestamp
    - ...

partnerBookmarks: userUid
    - postId: timestamp
    - ...

likes: userUid
    - postId: true
    - ...

postData: postId
  - title
  - category
  - imageUrl
  - contentText
  - authorRef: user

postDataForLists: postId #Could also be generated by a cloud function to avoid duplicating
  - title
  - imageUrl
  - category

postLikes: postId #Here,separating also enable a rule to prevent authors changing these fields.
  - totalLikes
  - totalFavorites

此结构分开了关注点，但是由于Firestore会为每个读取操作收费，因此我也对此进行了质疑。

我是Firebase的新手，我希望一开始就避免设计错误。请随时对结构进行评价，并在需要时提出其他问题。

谢谢

解决方法

好吧，我相信这很大程度上取决于您的应用最终的行为方式（以及用户实际使用您的应用的方式）。

但是我相信，零散的结构可以节省一些读取，但是最终需要一些复合索引来进行特定的交互，最终可以在应用程序中使用它们。我相信您可以在云firestore documentation上清除此查询，并观看他们在那里的视频内容，也许可以帮助您找到最适合自己的方法。