在 Firestore 中构建此类数据的正确方法是什么？

Question

我看过视频并阅读了来自 Google Firebase 服务的 Cloud Firestore 文档，但我无法从实时数据库中看出这一点。

我有这个网络应用程序，我想在其中存储来自不同类别产品的提供程序。 我想在我的所有产品中执行搜索查询，以找到我为此类产品提供的供应商，并最终访问该供应商信息。

我打算为此目的使用此结构：

Providers ( Collection )
   Provider 1 ( Document )
      Name
      City
      Categories
   Provider 2
      Name
      City

Products ( Collection )
   Product 1 ( Document )
      Name
      Description
      Category
      Provider ID
   Product 2
      Name
      Description
      Category
      Provider ID

所以我的问题是，一旦我得到我想要的产品，这种方法是否是访问提供商信息的正确方法？

我知道这在实时数据库中是可能的，使用提供者 ID 我可以在提供者部分搜索该提供者，但是对于 Firestore，我不确定它是否可能或者这是否是正确的方法。

Answer 1

在 Firestore 中构建此类数据的正确方法是什么？

您需要知道构建 Cloud Firestore 数据库没有“完美”、“最佳”或“正确”的解决方案。 最佳和正确的解决方案是满足您的需求并使您的工作更轻松的解决方案。 还要记住，NoSQL 数据库世界中也没有单一的“正确的数据结构”。 所有数据都经过建模以允许您的应用程序所需的用例。 这意味着对一个应用程序有效的方法对于另一个应用程序可能是不够的。 所以没有适合所有人的正确解决方案。 NoSQL 类型数据库的有效结构完全取决于您打算如何查询它。

您构建数据的方式对我来说看起来不错。 一般来说，有两种方法可以实现相同的目标。 第一种方法是在产品对象中保留对提供者的引用（正如您已经这样做的那样）或在产品文档中复制整个提供者对象。 最后一种技术称为denormalization ，在 Firebase 中是一种非常常见的做法。 所以我们经常在 NoSQL 数据库中复制数据，以适应否则可能无法实现的查询。 为了更好地理解，我建议您观看此视频， Firebase 数据库的非规范化是正常的。 它适用于 Firebase 实时数据库，但同样的原则也适用于 Cloud Firestore。

此外，当您复制数据时，需要记住一件事。 同样，您正在添加数据，您需要对其进行维护。 换句话说，如果你想更新/删除一个提供者对象，你需要在它存在的每个地方都这样做。

您现在可能想知道哪种技术最好。 一般而言，在 NoSQL 数据库中存储引用或重复数据的最佳方式完全取决于您的项目需求。

因此，您应该问自己一些有关要复制的数据的问题，或者只是将其保留为参考：

1. 是静态的还是会随着时间而改变？
2. 如果是这样，您是否需要更新数据的每个重复实例，以便它们都保持同步？ 这也是我前面提到的。
3. 谈到 Firestore，您是针对性能还是成本进行优化？

如果您的重复数据需要同时更改并保持同步，那么您将来可能很难将所有这些重复数据保持最新。 这也可能意味着您要花费大量资金来保持所有这些文档的新鲜度，因为每次更改都需要对每个文档进行读写。 在这种情况下，仅持有参考将是获胜的变体。

在这种方法中，您编写的重复数据很少（几乎只是Provider ID ）。 所以这意味着您编写这些数据的代码将非常简单且非常快速。 但是在读取数据时，您需要从两个集合中加载数据，这意味着额外的数据库调用。 对于合理数量的文档，这通常不是一个大的性能问题，但肯定需要更多的代码和更多的 API 调用。

如果您需要非常快的查询，您可能希望复制更多数据，以便客户端只需读取每个查询项目的一个文档，而不是多个文档。 但是您也可以依赖本地客户端缓存来降低成本，具体取决于客户端必须读取的数据。

在这种方法中，您为每个product文档复制provider所有数据。 这意味着编写此数据的代码更复杂，而且您肯定要存储更多数据，每个产品文档一个更多提供程序对象。 而且您需要弄清楚是否以及如何保持每个文档的最新状态。 但另一方面，阅读product文档现在可以在一次阅读中为您提供有关provider文档的所有信息。

这是 NoSQL 数据库中的一个常见考虑因素：您通常必须考虑写入性能和磁盘存储与读取性能和可扩展性。

对于您选择是否复制某些数据，它高度依赖于您的数据及其特征。 您必须根据具体情况考虑。

所以最后，请记住，这两种方法都是有效的方法，并且它们中的任何一个都不比另一个更好。 这完全取决于您的用例是什么，以及您对这种复制数据的新技术的适应程度。 数据复制是加快读取速度的关键，不仅在 Cloud Firestore 或 Firebase 实时数据库中，而且在一般情况下都是如此。 每当您将相同的数据添加到不同的位置时，您都是在复制数据以提高读取性能。 不幸的是，作为回报，您有更复杂的更新和更高的存储/内存使用。 但是需要注意的是，Firebase 实时数据库中的额外调用并不昂贵，在 Firestore 中是。 多少重复数据与额外的数据库调用最适合您，取决于您的需求以及您是否愿意放弃“单点定义思维”，这可以称为非常主观。

在完成了几个 Firebase 项目后，我发现如果我复制数据，我的阅读代码会变得非常简单。 但当然，同时编写代码会变得更加复杂。 这是这两者与您的需求之间的权衡，决定了您的应用程序的最佳解决方案。 此外，更准确地说，您还可以使用现有工具测量应用程序中发生的情况并做出相应决定。 我知道这不是具体的建议，而是软件开发。 一切都是关于衡量事物的。

还要记住，一些数据库结构更容易受到一些安全规则的保护。 因此，请尝试找到可以使用Cloud Firestore 安全规则轻松保护的架构。

另请查看我在这篇文章中的回答，我在这篇文章中详细解释了 Firestore 中的collections 、 maps和arrays 。