Firebase 数据结构和网址 [英] Firebase data structure and url
问题描述
我是 Firebase 和 nosql 的新手，所以请耐心使用对 sql 的引用.所以我的问题是如何在 firebase 中构建数据?
I'm new in Firebase and nosql so bear with me to use reference to sql. So my question is how to structure the data in firebase?
在firebase中，这是否意味着mysql中的每个新firebase"=新数据库"或表"?
In firebase, is that mean every "new firebase" = "new Database" or "table" in mysql?
如果在我的实时网络应用中，我有用户和评论.在 mysql 中，我将创建一个用户和一个评论表，然后将它们链接在一起.
If in my real time web app, I have users and comments. In mysql, I will create a users and a comments table then link them together.
我如何在 firebase 中构建它?
How do I structure this in firebase?
推荐答案
如果你有用户和评论，你可以很容易地像这样建模:
If you have users and comments, you could easily model it like this:
ROOT
|
+-- vzhen
| |
| +-- Vzhen's comment 1
| |
| +-- Vzhen's comment 2
|
+-- Frank van Puffelen
|
+-- Frank's comment 1
|
+-- Frank's comment 2
但是更有可能存在第三方实体，例如文章，并且用户正在评论(彼此的)文章.
However it is more likely that there is a third entity, like an article, and that users are commenting on (each other's) articles.
Firebase 没有外键的概念，但很容易模仿.如果你这样做，你可以像这样对用户/文章/评论结构进行建模:
Firebase doesn't have the concept of a foreign key, but it's easy to mimic it. If you do that, you can model the user/article/comment structure like this:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| |
| +-- Text of article 2 (AID=2)
|
+-- USERS
| |
| +-- vzhen (UID=1056201)
| |
| +-- Frank van Puffelen (UID=209103)
|
+-- COMMENTS
| |
| +-- Vzhen's comment on Article 1 (CID=1)
| |
| +-- Frank's response (CID=2)
| |
| +-- Frank's comment on article 2 (AID=2,UID=209103)
|
+-- ARTICLE_USER_COMMENT
|
+-- (AID=1,UID=1056201,CID=1)
|
+-- (AID=1,UID=209103,CID=2)
|
+-- (AID=2,UID=209103,CID=3)
这是您在关系数据库中建模的方式的直接映射.此模型的主要问题是您需要执行多少次查找才能获得单个屏幕所需的信息.
This is a quite direct mapping of the way you'd model this in a relational database. The main problem with this model is the number of lookups you'll need to do to get the information you need for a single screen.
- 阅读文章本身(来自文章节点)
- 阅读有关评论的信息(来自 ARTICLE_USER_COMMENT 节点)
- 阅读评论内容(来自 COMMENTS 节点)
根据您的需要，您甚至可能还需要读取 USERS 节点.
Depending on your needs, you might even need to also read the USERS node.
请记住，Firebase 没有 WHERE 子句的概念，它允许您仅从 ARTICLE_USER_COMMENT 中选择与特定文章或特定用户匹配的元素.
And keep in mind that Firebase does not have the concept of a WHERE clause that allows you to select just the elements from ARTICLE_USER_COMMENT that match a specific article, or a specific user.
在实践中这种映射结构的方式是不可用的.Firebase 是一种分层数据结构，因此我们应该使用比更传统的关系模型赋予我们的独特能力.例如:我们不需要ARTICLE_USER_COMMENT节点，我们可以直接在每篇文章、用户和评论本身下保留这些信息.
In practice this way of mapping the structure is not usable. Firebase is a hierarchical data structure, so we should use the unique abilities that gives us over the more traditional relational model. For example: we don't need a ARTICLE_USER_COMMENT node, we can just keep this information directly under each article, user and comment itself.
这是一个小片段:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| . |
| . +-- (CID=1,UID=1056201)
| . |
| +-- (CID=2,UID=209103)
|
+-- USERS
| |
| +-- vzhen (UID=1056201)
| . |
| . +-- (AID=1,CID=1)
| .
|
+-- COMMENTS
|
+-- Vzhen's comment on Article 1 (CID=1)
|
+-- Frank's response (CID=2)
|
+-- Frank's comment on article 2 (CID=3)
您可以在这里看到，我们正在通过文章和用户节点传播来自 ARTICLE_USER_COMMENT 的信息.这是对数据进行了一些非规范化处理.结果是当用户向文章添加评论时，我们需要更新多个节点.在上面的例子中，我们必须添加评论本身，然后将节点添加到相关的用户节点和文章节点.优点是当我们需要显示数据时，我们需要读取的节点更少.
You can see here, that we're spreading the information from ARTICLE_USER_COMMENT over the article and user nodes. This is denormalizing the data a bit. The result is that we'll need to update multiple nodes when a user adds a comment to an article. In the example above we'd have to add the comment itself and then the nodes to the relevant user node and article node. The advantage is that we have fewer nodes to read when we need to display the data.
如果你把这种非规范化发挥到极致，你最终会得到这样的数据结构:
If you take this denormalization to its most extreme, you end up with a data structure like this:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| | |
| | +-- Vzhen's comment on Article 1 (UID=1056201)
| | |
| | +-- Frank's response (UID=209103)
| |
| +-- Text of article 2 (AID=2)
| |
| +-- Frank's comment on Article 2 (UID=209103)
|
+-- USERS
|
+-- vzhen (UID=1056201)
| |
| +-- Vzhen's comment on Article 1 (AID=1)
|
+-- Frank van Puffelen (UID=209103)
|
+-- Frank's response (AID=1)
|
+-- Frank's comment on Article 2 (AID=2)
您可以看到我们在最后一个示例中去掉了 COMMENTS 和 ARTICLE_USER_COMMENT 节点.关于一篇文章的所有信息现在直接存储在文章节点本身下，包括对该文章的评论(带有指向发表评论的用户的链接").并且关于用户的所有信息现在都存储在该用户的节点下，包括用户发表的评论(带有指向评论所涉及文章的链接").
You can see that we got rid of the COMMENTS and ARTICLE_USER_COMMENT nodes in this last example. All the information about an article is now stored directly under the article node itself, including the comments on that article (with a "link" to the user who made the comment). And all the information about a user is now stored under that user's node, including the comments that user made (with a "link" to the article that the comment is about).
该模型唯一仍然棘手的是 Firebase 没有 API 来遍历此类链接"，因此您必须自己查找用户/文章.如果您使用 UID/AID(在本例中)作为标识用户/文章的节点的名称，这会变得容易得多.
The only thing that is still tricky about this model is the fact that Firebase doesn't have an API to traverse such "links", so you will have to look up the user/article up yourself. This becomes a lot easier if you use the UID/AID (in this example) as the name of the node that identifies the user/article.
这导致我们的最终模型:
So that leads to our final model:
ROOT
|
+-- ARTICLES
| |
| +-- AID_1
| | |
| | +-- Text of article 1
| | |
| | +-- COMMENTS
| | |
| | +-- Vzhen's comment on Article 1 (UID=1056201)
| | |
| | +-- Frank's response (UID=209103)
| |
| +-- AID_2
| |
| +-- Text of article 2
| |
| +-- COMMENTS
| |
| +-- Frank's comment on Article 2 (UID=209103)
|
+-- USERS
|
+-- UID_1056201
| |
| +-- vzhen
| |
| +-- COMMENTS
| |
| +-- Vzhen's comment on Article 1 (AID=1)
|
+-- UID_209103
|
+-- Frank van Puffelen
|
+-- COMMENTS
|
+-- Frank's response (AID=1)
|
+-- Frank's comment on Article 2 (AID=2)
我希望这有助于理解分层数据建模和所涉及的权衡.
I hope this helps in understanding hierarchical data-modelling and the trade-offs involved.
这篇关于Firebase 数据结构和网址的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
