在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.

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

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 one correct solution for everyone. An effective structure for a NoSQL type database is entirely dependent on how you intend to query it.

您构建数据的方式对我来说很好.通常，有两种方法可以实现相同的目的.第一个是在产品对象中保留提供者的引用(就像您已经做的那样)，或者在产品文档中复制整个提供者对象.最后一种技术称为denormalization，在涉及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 same principles apply to Cloud Firestore.

此外，在复制数据时，需要记住一件事.用与添加数据相同的方式，您需要对其进行维护.换句话说，如果要更新/删除提供程序对象，则需要在它存在的每个位置进行操作.

Also, when you are duplicating data, there is one thing that need to keep in mind. In the same way you are adding data, you need to maintain it. With 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时，您是否在优化性能或费用?

1. Is the static or will it change over time?
2. If it does, do you need to update every duplicated instance of the data so they all stay in sync? This is what I have also mentioned earlier.
3. When it comes to Firestore, are you optimizing for performance or cost?

如果重复的数据需要同时更改并保持同步，那么将来可能很难将所有重复的数据保持最新状态.这也可能意味着您要花很多钱来使所有这些文档保持最新状态，因为每次更改都需要对每个文档进行读写操作.在这种情况下，仅保留引用将成为获胜者.

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文档现在可以在一个阅读中为您提供有关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 it up to date each document. But on the other hand, reading an 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 read 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 favour 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 the concrete recommendation but that's software development. Everything is about measuring things.

还请记住，某些数据库结构更易于通过某些安全规则进行保护.因此，尝试使用 Cloud Firestore安全规则 a>.

Remember also, that some database structures are easier to be protected with some security rules. So try to find a schema that can be easy 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屋！