Firebase Cloud Firestore 中的非规范化是什么? [英] What is denormalization in Firebase Cloud Firestore?
问题描述
在谈论 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.
推荐答案
Firebase Cloud Firestore 中的非规范化是什么?
What is denormalization in Firebase Cloud Firestore?
非规范化不仅与 Cloud Firestore 相关，也是 NoSQL 数据库中常用的技术.
The denormalization is not related only to Cloud Firestore, is a technique generally used in NoSQL databases.
这种非规范化到底是什么?
What is really this denormalization?
反规范化是优化 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.
这种非规范化到底有什么帮助?
How does this denormalization really help?
是的，确实如此.对于 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.
数据库扁平化和非规范化是一回事吗?
Is database flatten and denormalization the same thing?
让我们举一个例子.假设我们有一个用于测验应用程序的数据库架构，如下所示:
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 ->标签 ->tagId 如同 tags ->标签标识.所以我们将数据展平，以某种方式对现有数据进行分组.
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 separate logical 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 中的非规范化是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
