如果您有用户和评论,则可以像下面这样轻松建模:
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)
我希望这有助于理解分层数据建模和所涉及的取舍。