Android 如何处理google Firestore中的外键类情况？

由于Firestore中没有像MYSQL那样的外键功能，因此我无法复制我的一个重要功能，即在一个位置更新文件，它将反映在每个位置。此外，Firebase没有一次更新所有文档特定文件的功能

---

这类问题已经存在，但我无法找到解决方案。假设我有一百万份文件，其中包含一个文件，它是一种材料的密度。后来，我发现我的密度值是错误的，所以如何在所有文档中有效地更新该值。另外，我不想使用server/admin SDK。

如果需要更改100万个文档的内容，则需要查询这100万个文档，迭代结果，然后分别更新其中的每个文档

---

在一个查询中更新多个文档的sql“update where”语句是不等价的。它要求每个文档更新一次。

如果不想使用Admin SDK，那么您可以选择更新客户端上的

densityMaterial

属性的值，这可能不是最佳解决方案。但是，如果可以将更新操作划分为较小的块，则可能会成功

如果您使用POJO类来映射每个文档，那么您可能会对以下帖子中的答案感兴趣：

如果您没有使用POJO类，请查看我在以下帖子中的答案：

关于成本，您将为每一个更新的文档支付一次写入操作的费用。如果所有1 MIL文档都将更新，那么您将收到1 MIL写入操作的账单

---

编辑：

假设我有一百万份文件，其中包含一个文件，它是一种材料的密度。后来，我发现我的密度值是错误的，所以如何在所有文档中有效地更新该值

如果所有这些1 MIL文档都包含一个名为

densityMaterial

的属性，该属性具有完全相同的值，那么在每个文档中存储该属性就没有任何意义。您可以创建一个包含该特定值的文档，在这1 MIL的每个文档中，只需添加对该文档的引用即可。DocumentReference是一种文档引用。现在，如果您需要更改该值，它将只导致一次文档写入

但是，如果

densityMaterial

属性的值不同，且所有值都错误，则数据库没有问题，添加数据的机制/人员也有问题。如果您添加了1 MIL不正确的文档，这不是数据库问题

为什么不选择MySQL呢

MySQL无法像CloudFireStore那样扩展。Firestore只是大规模扩展

我能避免这个问题吗

---

是的，您可以使用单个文档购买这些详细信息。

您可以在android的上下文中详细说明代码吗？我不想使用AdminSDK。这又会产生怎样的效果、成本和效率？因为在sql中，你可以只在一个地方进行更新，而另一方面，你必须更新一百万个文档，你没有义务使用AdminSDK。对于任何其他平台，更新策略都不会改变。正如我所说，FIrestore没有一个“updatewhere”命令可以在一个查询中更新多个文档。那么，如果一次更新花费这么多，为什么要选择Firestore呢？对于这个特定的问题有没有未来的计划？如果你更新了一百万份文件，那就是你必须支付的费用。如果您在一个SQL数据库中更新了相似数量的对象，恐怕在成本方面也会相似。是的，检查一下。但在MYSQL中，我只需要在一个地方更新东西，它会通过外键引用在其他地方自动传播，对吗？NoSQL世界中的概念与SQL中的概念不同。如果您认为Cloud Firestore对于您的应用程序的用例来说是昂贵的，您可能会尝试使用，即使您正在丢失Cloud Firestore拥有的一些查询功能。我没有具体的用例，这是一种常见的情况，您会更新一些错误，并且您希望它会传播到所有其他地方。在mysql中，我们在一个地方执行此操作，而在Firestore中，您可以在每个地方执行此操作。那么，如何在没有任何效率和财政负担的情况下管理这件事。。。。这就是我想要问的。