问题描述
我有一个基本的应用程序,看起来像一个博客,在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上清除此查询,并观看他们在那里的视频内容,也许可以帮助您找到最适合自己的方法。