firebase 中的数据结构有哪些好方法？

Question

我从 Firebase 开始，想知道什么是最有效的数据结构方式

让我们以一个简单的社交媒体应用程序为例，其中只能共享照片（就像 Instagram 的开端）。

1. 用户上传带有一些元数据的照片（描述）

2. （Home Feed）用户（关注者）将按时间顺序看到帖子，而在场外会有其他功能，如（喜欢帖子、保存、评论）

3. 搜索和关注用户

4. 关于喜欢和评论的通知

5. 在评论中搜索

什么是存储数据的良好结构和尽快获取数据的有效方法

Answer 1

我会提前 go 并留下我将如何处理这个问题的答案。 即使问题被标记为实时数据库，我的回答也将更倾向于 Firestore。 有多种方法来构造数据。 这是我给你的例子使用的一般结构：

users
    - name
    - timestamp

posts
    - imageURL
    - description
    - timestamp
    - likeCount
    - commentCount

posts/comments //subcollection
    - userID
    - comment
    - timestamp
    
posts/likes //subcollection
    - userID
    - timestamp
    
savedposts
    - postID
    - userID

followers
    - userID
    - followedID

一些附加说明：

图片上传

这里最好的选择是将图像上传到云存储并利用云 function 生成公共 URL 并将其保存到帖子文档中。

评论/用户搜索

如我的评论所述，Firebase 没有针对基于文本的搜索的出色解决方案。 我在项目中使用的解决方案是利用云 function 使 Algolia 索引与我的users集合保持同步。 然后，我通过可调用云 function 将用户搜索卸载给他们——尽管如果需要，您可以直接在您的应用程序中使用 Algolia 客户端 SDK。 在您的场景中，您还必须使所有评论保持同步。 Algolia 不是一项便宜的服务，因此我会研究使用文档中列出的其他选项的优缺点。

文档 ID

我通常让 Firestore 自动识别文件，但在这里我会做一些例外。 对于已保存的帖子和followers savedposts ，我将分别使用{userID}{postID}和{userID}{followedID}的（手动）复合 ID。 它允许您执行不喜欢和取消关注的简单操作，而无需先查询文档。 例如） firestore().collection('postsaves').doc(`${userID}${postID}`).delete()

最后的想法

您提到可能会迁移到 AWS。 我在 Firebase 的工作比在 AWS 多得多，但我都做了。 在我看来，Firebase 在可用性和文档方面都是无与伦比的。 在功能和微调方面有一些妥协，但如果缺乏文本搜索是唯一的障碍，我建议坚持使用 Firebase。