60

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

在firebase中，这是否意味着mysql中的每个“新firebase”=“新数据库”或“表”？

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

我如何在firebase中构建它？

4

1 回答 1

158

如果你有用户和评论，你可以很容易地像这样建模：

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)

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

于 2013-05-20T13:55:13.990 回答