火力地堡数据结构和网址火力地堡数据结构和网址(Firebase data structure and

我在火力地堡新的和我的NoSQL所以舍不得用参考SQL。所以我的问题是如何结构火力点的数据？

在火力点，是意味着在mysql中的每一个“新的火力点” =“新数据库”或“表”？

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

如何在火力结构呢？

如果您的用户和评论，你可以很容易就喜欢这种模式：

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

然而，更有可能的是还有第三个实体，就像一个项目，并且该用户评论（对方的）文章。

火力地堡没有一个外键的概念，但它很容易模仿它。如果你这样做，你可以模拟用户/文章/评论结构是这样的：

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)

这是你在一个关系数据库模型这种方式相当直接映射。这种模式的主要问题是，你需要做的就是你需要一个单一的屏幕上的信息查找的数量。

阅读文章本身（从文章节点）
阅读关于评论的信息（从ARTICLE_USER_COMMENT节点）
阅读评论的内容（从注释节点）

根据您的需求，您甚至可能还需要参考用户节点。

而且要记住，火力地堡没有一个WHERE子句允许您选择刚刚从ARTICLE_USER_COMMENT符合特定物品或特定用户的元素的概念。

在实践中映射结构的这种方式是不可用的。火力地堡是一个分层的数据结构，所以我们应该用独特的能力，让我们在更传统的关系模型。例如：我们不需要一个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)

你可以看到，我们得到了最后的例子，摆脱了意见和ARTICLE_USER_COMMENT节点。有关项目的所有信息现在都直接存储在文章节点自身下，包括对文章的评论（用“链接”到谁提出的评论的用户）。而所有关于用户的信息现在存储用户的节点下，包括用户提出的意见（有一个“链接”的文章，该评论是有关）。

这仍然是棘手的这个模型的唯一的事情是事实，火力地堡没有一个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)

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