Firebase数据结构和网址

Question

Firebase数据结构和网址

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

在firebase中，这是指mysql中的每个“新firebase”=“新数据库”还是“表”？

如果在我的实时网络应用程序中，我有用户和评论。在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)这是您在关系数据库中对此进行建模的方式的直接映射。此模型的主要问题是您需要执行的查找次数才能获得单个屏幕所需的信息。阅读文章本身（来自ARTICLES节点）阅读有关注释的信息（来自ARTICLE_USER_COMMENT节点）阅读评论的内容（来自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)我希望这有助于理解分层数据建模和所涉及的权衡。