Firebase数据结构和url
我是Firebase和nosql的新成员，所以请使用引用sql的脚本。 所以我的问题是如何构buildFirebase中的数据？
在firebase中，是指mysql中的每个“新的firebase”=“新的数据库”或“表”？
如果在我的实时networking应用程序，我有用户和评论。 在MySQL中，我将创build一个用户和一个评论表，然后将它们链接在一起。
如何在Firebase中构build这个结构？
谢谢
如果你有用户和评论，你可以像这样轻松地build模：
ROOT | +-- vzhen | | | +-- Vzhen's comment 1 | | | +-- Vzhen's comment 2 | +-- Frank van Puffelen | +-- Frank's comment 1 | +-- Frank's comment 2 然而，更有可能是第三个实体，就像一篇文章，并且用户正在评论（彼此的）文章。
Firebase没有外键的概念，但很容易模仿它。 如果你这样做，你可以像这样build模用户/文章/评论结构：
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节点）
- 阅读评论的内容（从评论节点）
根据您的需要，您甚至可能还需要阅读USERS节点。
请记住，Firebase没有WHERE子句的概念，只允许您从ARTICLE_USER_COMMENT中select与特定文章或特定用户相匹配的元素。
实际上，这种映射结构的方式是不可用的。 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的信息传播到文章和用户节点上。 这是反常规的数据了一下。 结果是，当用户向文章添加评论时，我们需要更新多个节点。 在上面的例子中，我们必须添加评论本身，然后将节点添加到相关的用户节点和文章节点。 好处是当我们需要显示数据时，我们有更less的节点可以读取。
如果你把这个非规范化最极端的话，你会得到这样一个数据结构：
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)
我希望这有助于理解分层数据build模和所涉及的权衡。
