Firebase数据结构和URL [英] Firebase data structure and url
问题描述
所以我的问题是如何在firebase中构造数据？
在firebase中，这意味着每个new firebase=new Database或table 在mysql？
如果在我的实时Web应用程序，我有用户和评论。
在mysql中，我将创建一个用户和一个注释表，然后将它们链接在一起。
如何在firebase中结构化？
感谢adv
如果您有用户和评论，您可以轻松地将其建模这个：
ROOT
|
+ - vzhen
| |
| + - Vzhen的评论1
| |
| + - Vzhen的评论2
|
+ - Frank van Puffelen
|
+ - 弗兰克的评论1
|
+ - 弗兰克的评论2
然而，有可能是第三个实体，就像一篇文章，用户在评论（对方的）文章。
Firebase没有外键的概念，但很容易模仿它。如果你这样做，你可以这样模拟用户/文章/评论结构：
ROOT
|
+ - ARTICLES
| |
| + - 文章1（AID = 1）
| |
| + - 文章2（AID = 2）
|
+ - USERS
| |
| + - vzhen（UID = 1056201）
| |
| + - Frank van Puffelen（UID = 209103）
|
+ - 评论
| |
| + - Vzhen对第1条的评论（CID = 1）
| |
| + - 弗兰克的回应（CID = 2）
| |
| + - 弗兰克对第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）
是在关系数据库中建模的方式的一个非常直接的映射。这个模型的主要问题是您需要做的一些查找信息才能获取单个屏幕所需的信息。
- 阅读文章本身（来自ARTICLES节点）
- 阅读有关评论的信息（来自ARTICLE_USER_COMMENT节点）
- 阅读评论内容（从COMMENTS节点）
根据您的需要，您甚至可能还需要阅读USERS节点。
请记住，Firebase不具有WHERE子句的概念，允许您只从ARTICLE_USER_COMMENT中选择与特定文章或特定用户匹配的元素。
在实践中，这种映射结构的方法是不可用的。 Firebase是一个分层的数据结构，所以我们应该使用独特的能力，使我们更加传统的关系模型。例如：我们不需要一个ARTICLE_USER_COMMENT节点，我们可以直接在每个文章，用户和评论本身下保留这些信息。
一个小的代码片段： / p>
ROOT
|
+ - ARTICLES
| |
| + - 文章1（AID = 1）
| 。 |
| 。 + - （CID = 1，UID = 1056201）
| 。 |
| + - （CID = 2，UID = 209103）
|
+ - USERS
| |
| + - vzhen（UID = 1056201）
| 。 |
| 。 + - （AID = 1，CID = 1）
| 。
|
+ - 评论
|
+ - Vzhen对第1条的评论（CID = 1）
|
+ - 弗兰克的回应（CID = 2）
|
+ - 弗兰克对第2条的评论（CID = 3）
你可以在这里看到我们正在从ARTICLE_USER_COMMENT传播关于文章和用户节点的信息。这是一个非正规化的数据。结果是当用户向文章添加注释时，我们需要更新多个节点。在上面的例子中，我们必须将注释本身，然后将节点添加到相关的用户节点和文章节点。优点是当我们需要显示数据时，我们有更少的节点要读取。
如果你把这个非规范化转化为最极端的话，你最终会得到一个数据结构像这样：
ROOT
|
+ - ARTICLES
| |
| + - 文章1（AID = 1）
| | |
| | + - Vzhen对第1条的评论（UID = 1056201）
| | |
| | + - 弗兰克的回应（UID = 209103）
| |
| + - 文章2（AID = 2）
| |
| + - 弗兰克对第2条的评论（UID = 209103）
|
+ - USERS
|
+ - vzhen（UID = 1056201）
| |
| + - Vzhen对第1条的评论（AID = 1）
|
+ - Frank van Puffelen（UID = 209103）
|
+ - 弗兰克的回应（AID = 1）
|
+ - 弗兰克对第2条的评论（AID = 2）
你可以看到我们在上一个例子中摆脱了COMMENTS和ARTICLE_USER_COMMENT节点。所有关于文章的信息现在直接存储在文章节点本身，包括对该文章的评论（与发表评论的用户的链接）。并且所有关于用户的信息现在都存储在该用户的节点下，包括用户所做的评论（与该评论的文章链接）。
对于这个模型来说，唯一仍然很棘手的是Firebase没有API来遍历这样的链接，所以你必须自己查找用户/文章。如果您使用UID / AID（在本示例中）作为标识用户/文章的节点的名称，这将变得更加容易。
因此，导致我们最终模型：
ROOT
|
+ - ARTICLES
| |
| + - AID_1
| | |
| | + - 文章1
| | |
| | + - 评论
| | |
| | + - Vzhen对第1条的评论（UID = 1056201）
| | |
| | + - 弗兰克的回应（UID = 209103）
| |
| + - AID_2
| |
| + - 文章2
| |
| + - 评论
| |
| + - 弗兰克对第2条的评论（UID = 209103）
|
+ - USERS
|
+ - UID_1056201
| |
| + - vzhen
| |
| + - 评论
| |
| + - Vzhen对第1条的评论（AID = 1）
|
+ - UID_209103
|
+ - Frank van Puffelen
|
+ - 评论
|
+ - 弗兰克的回应（AID = 1）
|
+ - 弗兰克对第2条的评论（AID = 2）
我希望这有助于理解分层数据建模和涉及的权衡。
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?
In firebase, is that mean every "new firebase" = "new Database" or "table" in 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.
How do I structure this in firebase?
Thank in adv
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 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.
- Read the article itself (from the ARTICLES node)
- Read the information about the comments (from the ARTICLE_USER_COMMENT node)
- Read the content of the comments (from the COMMENTS node)
Depending on your needs, you might even need to also read the USERS node.
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.
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.
A small snippet of this:
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)
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)
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).
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数据结构和URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
