在 Firestore 中构建此类数据的正确方法是什么? [英] What is the correct way to structure this kind of data in Firestore?

问题描述

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

I have seen videos and read the documentation of Cloud firestore, from Google Firebase service, but I can't figure this out coming from realtime database.

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

I have this web app in mind in which I want to store my providers from different category of products. I want perform a search query through all my products to find what providers I have for such product, and eventually access that provider info.

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

I am planning to use this structure for this purpose:

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

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

So my question is, is this approach the right way to access the provider info once I get the product I want?

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

I know this is possible in the realtime database, using the provider ID I could search for that provider in the providers section, but with Firestore I am not sure if its possible or if this is right approach.

推荐答案

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

What is the correct way to structure this kind of data in Firestore?

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

You need to know that there is no "perfect", "the best" or "the correct" solution for structuring a Cloud Firestore database. The best and correct solution is the solution that fits your needs and makes your job easier. Bear also in mind that there is also no single "correct data structure" in the world of NoSQL databases. All data is modeled to allow the use-cases that your app requires. This means that what works for one app, may be insufficient for another app. So there is not a correct solution for everyone. An effective structure for a NoSQL type database is entirely dependent on how you intend to query it.

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

The way you are structuring your data looks good to me. In general, there are two ways in which you can achieve the same thing. The first one would be to keep a reference of the provider in the product object (as you already do) or to copy the entire provider object within the product document. This last technique is called denormalization and is a quite common practice when it comes to Firebase. So we often duplicate data in NoSQL databases, to suit queries that may not be possible otherwise. For a better understanding, I recommend you see this video, Denormalization is normal with the Firebase Database. It's for Firebase Realtime Database but the same principles apply to Cloud Firestore.

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

Also, when you are duplicating data, there is one thing that needs to keep in mind. In the same way, you are adding data, you need to maintain it. In other words, if you want to update/delete a provider object, you need to do it in every place that it exists.

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

You might wonder now, which technique is best. In a very general sense, the best way in which you can store references or duplicate data in a NoSQL database is completely dependent on your project's requirements.

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

So you should ask yourself some questions about the data you want to duplicate or simply keep it as references:

1. 是静态的还是会随着时间的推移而改变?
2. 如果是这样，您是否需要更新数据的每个重复实例，以便它们都保持同步?这也是我之前提到的.
3. 谈到 Firestore，您是针对性能还是费用?

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

If your duplicated data needs to change and stay in sync in the same time, then you might have a hard time in the future keeping all those duplicates up to date. This will also might imply you spend a lot of money keeping all those documents fresh, as it will require a read and write for each document for each change. In this case, holding only references will be the winning variant.

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

In this kind of approach, you write very little duplicated data (pretty much just the Provider ID). So that means that your code for writing this data is going to be quite simple and quite fast. But when reading the data, you will need to load the data from both collections, which means an extra database call. This typically isn't a big performance issue for reasonable numbers of documents, but definitely does require more code and more API calls.

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

If you need your queries to be very fast, you may want to prefer to duplicate more data so that the client only has to read one document per item queried, rather than multiple documents. But you may also be able to depend on local client caches makes this cheaper, depending on the data the client has to read.

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

In this approach, you duplicate all data for a provider for each product document. This means that the code to write this data is more complex, and you're definitely storing more data, one more provider object for each product document. And you'll need to figure out if and how to keep up to date on each document. But on the other hand, reading a product document now gives you all information about the provider document in one read.

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

This is a common consideration in NoSQL databases: you'll often have to consider write performance and disk storage vs. reading performance and scalability.

对于您选择是否复制某些数据，高度依赖于您的数据及其特征.您必须逐案考虑.

For your choice of whether or not to duplicate some data, it is highly dependent on your data and its characteristics. You will have to think that through on a case-by-case basis.

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

So in the end, remember that both are valid approaches, and neither of them is pertinently better than the other. It all depends on what your use-cases are and how comfortable you are with this new technique of duplicating data. Data duplication is the key to faster reads, not just in Cloud Firestore or Firebase Realtime Database but in general. Any time you add the same data to a different location, you're duplicating data in favor of faster read performance. Unfortunately in return, you have a more complex update and higher storage/memory usage. But you need to note that extra calls in Firebase real-time database, are not expensive, in Firestore are. How much duplication data versus extra database calls is optimal for you, depends on your needs and your willingness to let go of the "Single Point of Definition mindset", which can be called very subjective.

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

After finishing a few Firebase projects, I find that my reading code gets drastically simpler if I duplicate data. But of course, the writing code gets more complex at the same time. It's a trade-off between these two and your needs that determines the optimal solution for your app. Furthermore, to be even more precise you can also measure what is happening in your app using the existing tools and decide accordingly. I know that is not a concrete recommendation but that's software development. Everything is about measuring things.

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

Remember also, that some database structures are easier to be protected with some security rules. So try to find a schema that can be easily secured using Cloud Firestore Security Rules.

另请查看我在这篇帖子中的回答 我在其中详细解释了 Firestore 中的 collections、maps 和 arrays.

Please also take a look at my answer from this post where I have explained more about collections, maps and arrays in Firestore.

这篇关于在 Firestore 中构建此类数据的正确方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！