firebase mysql_nosql-Firebase数据结构和u

如果您有用户和评论，则可以像下面这样轻松建模：

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)

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