问题描述
在谈论Firebase Cloud Firestore时，这种非规范化实际上是什么?我在互联网上读了几篇文章，在这里有一些关于stackoverflow的答案，大多数答案都推荐这种方法.这种非规范化真正有什么帮助?总是有必要吗?
What is really this denormalization all about when talking about Firebase Cloud Firestore? I read a few articles on the internet and some answers here on stackoverflow and most of the answers recommend this approach. How does this denormalization really help? Is it always necessary?
数据库扁平化和非规范化是一回事吗?
Is database flatten and denormalization the same thing?
这是我的首要问题，希望我能找到一个可以帮助我理解这一概念的答案.我知道是不同的，但是我有两年的MySQL经验.
It's my fist question and hope I'll find an answer that can help me understand the concept. I know is different, but I have two years of experience in MySQL.
推荐答案
非规范化不仅与Cloud Firestore有关，这是NoSQL数据库中通常使用的一种技术.
The denormalization is not related only to Cloud Firestore, is a technique generally used in NoSQL databases.
反规范化是通过在数据库的其他不同位置添加冗余数据来优化NoSQL数据库性能的过程.我的意思是添加冗余数据，正如@FrankvanPuffelen在他的评论中已经提到的那样，这意味着我们复制一个地方另一个地方已经存在的完全相同的数据，以适应否则可能无法实现的查询.因此，非规范化有助于掩盖关系数据库固有的低效率.
Denormalization is the process of optimizing the performance of NoSQL databases, by adding redundant data in other different places in the database. What I mean by adding redundant data, as @FrankvanPuffelen already mentioned in his comment, it means that we copy the exact same data that already exists in one place, in another place, to suit queries that may not even be possible otherwise. So denormalization helps cover up the inefficiencies inherent in relational databases.
是的，确实如此.在Firebase上，这也是一种很常见的做法，因为数据复制是加快读取速度的关键.我看到您是NoSQL数据库的新手，因此为了更好地理解，我建议您观看此视频，使用Firebase数据库进行反规范化是正常的.它用于Firebase实时数据库，但相同的原理也适用于Cloud Firestore.
Yes, it does. It's also a quite common practice when it comes to Firebase because data duplication is the key to faster reads. I see you're new to the NoSQL database, so 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.
我们不只是为了使用非规范化而使用它.我们仅在绝对需要时使用它.
We don't use denormalization just for the sake of using it. We use it, only when it is definitely needed.
让我们举个例子.假设我们有一个测验应用程序的数据库架构，如下所示:
Let's take an example of that. Let's assume we have a database schema for a quiz app that looks like this:
Firestore-root
|
--- questions (collections)
|
--- questionId (document)
|
--- questionId: "LongQuestionIdOne"
|
--- title: "Question Title"
|
--- tags (collections)
|
--- tagIdOne (document)
| |
| --- tagId: "yR8iLzdBdylFkSzg1k4K"
| |
| --- tagName: "History"
| |
| --- //Other tag properties
|
--- tagIdTwo (document)
|
--- tagId: "tUjKPoq2dylFkSzg9cFg"
|
--- tagName: "Geography"
|
--- //Other tag properties
我们可以通过简单地将tags集合移动到一个单独的顶级集合中来扁平化数据库，如下所示:
We can flatten the database by simply moving the tags collection in a separate top-level collection like this:
Firestore-root
|
--- questions (collections)
| |
| --- questionId (document)
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- title: "Question Title"
|
--- tags (collections)
|
--- tagIdOne (document)
| |
| --- tagId: "yR8iLzdBdylFkSzg1k4K"
| |
| --- tagName: "History"
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- //Other tag properties
|
--- tagIdTwo (document)
|
--- tagId: "tUjKPoq2dylFkSzg9cFg"
|
--- tagName: "Geography"
|
--- questionId: "LongQuestionIdTwo"
|
--- //Other tag properties
现在，要获取与特定问题对应的所有标签，您只需查询tags集合，其中questionId属性保存所需的问题ID.
Now, to get all the tags that correspond to a specific question, you need to simply query the tags collection where the questionId property holds the desired question id.
或者您可以同时展平和取消规范化数据库，如以下模式所示:
Or you can flatten and denormalize the database at the same time, as you can see in the following schema:
Firestore-root
|
--- questions (collections)
| |
| --- questionId (document)
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- title: "Question Title"
| |
| --- tags (collections)
| |
| --- tagIdOne (document) //<----------- Same tag id
| | |
| | --- tagId: "yR8iLzdBdylFkSzg1k4K"
| | |
| | --- tagName: "History"
| | |
| | --- //Other tag properties
| |
| --- tagIdTwo (document) //<----------- Same tag id
| |
| --- tagId: "tUjKPoq2dylFkSzg9cFg"
| |
| --- tagName: "Geography"
| |
| --- //Other tag properties
|
--- tags (collections)
|
--- tagIdOne (document) //<----------- Same tag id
| |
| --- tagId: "yR8iLzdBdylFkSzg1k4K"
| |
| --- tagName: "History"
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- //Other tag properties
|
--- tagIdTwo (document) //<----------- Same tag id
|
--- tagId: "tUjKPoq2dylFkSzg9cFg"
|
--- tagName: "Geography"
|
--- questionId: "LongQuestionIdTwo"
|
--- //Other tag properties
请参见，users -> uid -> tags -> tagId中的标记对象与tags -> tagId中的相同.因此，我们将数据拼合以某种方式对现有数据进行分组.
See, the tag objects are the same as well in users -> uid -> tags -> tagId as in tags -> tagId. So we flatten data to group somehow existing data.
有关更多信息，您还可以查看:
For more information, you can also take a look at:
因为您说自己有SQL背景，请尝试考虑一种标准化设计，该设计通常会将不同但相关的数据存储在单独的位置逻辑表，称为关系.如果这些关系在物理上存储为单独的磁盘文件，则完成从多个关系中抽取信息的查询(联接操作)可能会很慢.如果加入许多关系，则可能会太慢.由于在NoSQL数据库中，我们没有"JOIN"子句，我们必须创建不同的解决方法才能获得相同的行为.
Because you say you have a SQL background, try to think at a normalized design which will often store different but related pieces of data in separatelogical tables, which are called relations. If these relations are stored physically as separate disk files, completing a query that draws information from several relations (join operations) can be slow. If many relations are joined, it may be prohibitively slow. Because in NoSQL databases, we do not have "JOIN" clauses, we have to create different workarounds to get the same behavior.
这篇关于什么是Firebase Cloud Firestore中的非规范化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！