时间戳

首页 > 解决方案 > Firestore，追随者数据结构

firebase - Firestore，追随者数据结构

问题描述

我只是在创建一个 Instagram 克隆应用程序进行测试

我的数据结构如下

   --- users (root collection)
         |
         --- uid (one of documents)
              |
              --- name: "name"
              |
              --- email: "email@email.com"
              |
              --- following (sub collection)
              |        |
              |        --- uid (one of documents)
              |            |
              |            --- customUserId : "blahblah"
              |            |
              |            --- name : "name"
              |            |
              |            --- pictureStorageUrl : "https://~~"
              |
              --- followers (sub collection)
              |        |
              |        --- uid (one of documents)
              |            |
              |            --- customUserId : "blahblah"
              |            |
              |            --- name : "name"
              |            |
              |            --- pictureStorageUrl : "https://~~"
              |

假设用户 A 有 100 万粉丝，那么如果用户 A 编辑了一张图片或姓名或 customUserId，是否应该修改每个“关注”100 万粉丝用户的子集合的文档？

应该有 100 万次更新吗？有没有更有效的救援方法？而如果没有其他好办法，在上述方法的情况下，通过云功能的数据库触发器批量修改数据是否合适呢？

标签： firebasegoogle-cloud-firestore

解决方案

100万粉丝的每个子集合“关注”的文档是否应该修改？应该有 100 万次更新吗？

这完全由您决定。如果您不想更新它们，那就不要。但是，如果您希望数据保持同步，则必须查找并更新复制该数据的所有文档。

有没有更有效的救援方法？

更新 100 万份文档？不可以。如果您有 100 万份文档要更新，那么您必须逐个查找并更新它们。

而如果没有其他好办法，在上述方法的情况下，通过云功能的数据库触发器批量修改数据是否合适呢？

在 Cloud Functions 中进行更新仍然需要 100 万次更新。这项工作没有任何捷径——前端和后端都是一样的。Cloud Functions 只会让您触发该工作在后端自动发生。

如果您想避免 100 万次更新，那么您不应该复制数据 100 万次。只需存储一个 UID，然后进行第二次查询以查找有关该用户的信息。

推荐阅读