Firebase 数据结构和 url

Question

我是 Firebase 和 nosql 的新手，所以请耐心等待我使用对 sql 的引用。所以我的问题是如何在 firebase 中构建数据？

在firebase中，这是否意味着mysql中的每个“new firebase”=“new Database”或“table”？

如果在我的实时网络应用程序中，我有用户和评论。在 mysql 中，我将创建一个用户和一个评论表，然后将它们链接在一起。

如何在 firebase 中构建它？

Answer 1

如果您有用户和评论，您可以轻松地像这样建模:

ROOT
 |
 +-- vzhen
 |     |
 |     +-- Vzhen's comment 1
 |     |
 |     +-- Vzhen's comment 2
 |
 +-- Frank van Puffelen
       |
       +-- Frank's comment 1
       |
       +-- Frank's comment 2

但是更有可能存在第三个实体，例如一篇文章，并且用​​户正在评论(彼此的)文章。

Firebase 没有外键的概念，但很容易模仿它。如果这样做，您可以对用户/文章/评论结构进行建模，如下所示:

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)
 

这是在关系数据库中建模的方式的非常直接的映射。此模型的主要问题是您需要进行大量查找才能获取单个屏幕所需的信息。

1. 阅读文章本身(从 ARTICLES 节点)
2. 读取有关评论的信息(来自 ARTICLE_USER_COMMENT 节点)
3. 阅读评论内容(从 COMMENTS 节点)

根据您的需要，您甚至可能还需要读取 USERS 节点。

请记住，Firebase 没有 WHERE 子句的概念，该子句允许您仅从 ARTICLE_USER_COMMENT 中选择与特定文章或特定用户匹配的元素。

实际上，这种映射结构的方式是不可用的。 Firebase 是一种分层数据结构，因此我们应该使用超越传统关系模型的独特功能。例如:我们不需要 ARTICLE_USER_COMMENT 节点，我们可以直接将此信息保留在每篇文章、用户和评论本身下。

其中的一小段:

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 的信息传播到文章和用户节点上。这使数据有点非规范化。结果是，当用户向文章添加评论时，我们需要更新多个节点。在上面的示例中，我们必须添加评论本身，然后将节点添加到相关的用户节点和文章节点。优点是当我们需要显示数据时，我们需要读取的节点较少。

如果您将这种非规范化发挥到极致，您最终会得到如下的数据结构:

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 节点。有关文章的所有信息现在都直接存储在文章节点本身下，包括该文章的评论(带有指向发表评论的用户的“链接”)。有关用户的所有信息现在都存储在该用户的节点下，包括用户发表的评论(带有指向该评论所涉及文章的“链接”)。

此模型唯一棘手的问题是 Firebase 没有 API 来遍历此类“链接”，因此您必须自己查找用户/文章。如果您使用 UID/AID(在本例中)作为标识用户/文章的节点名称，这会变得容易得多。

这就是我们的最终模型:

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)

我希望这有助于理解分层数据建模和所涉及的权衡。