Firebase數據結構和網址

Question

我是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) 

這是你在一個關係數據庫模型這種方式相當直接映射。這種模式的主要問題是您需要做的查找次數，以獲取單個屏幕所需的信息。

1. 閱讀文章本身（從文章節點）
2. 閱讀有關評論的信息（從ARTICLE_USER_COMMENT節點）
3. 閱讀評論的內容（從註釋節點）

根據您的需要，您甚至可能還需要閱讀USERS節點。

請記住，Firebase沒有WHERE子句的概念，只允許您從ARTICLE_USER_COMMENT中選擇與特定文章或特定用戶相匹配的元素。

實際上，這種映射結構的方法是不可用的。 Firebase是一種分層次的數據結構，因此我們應該使用獨特的能力，讓我們瞭解更傳統的關係模型。例如：我們不需要ARTICLE_USER_COMMENT節點，我們可以直接在每篇文章，用戶和評論本身下面保存這些信息。

A的這個小片段：

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節點。所有關於文章的信息現在直接存儲在文章節點本身下，包括對該文章的評論（與發表評論的用戶的「鏈接」）。所有關於用戶的信息現在都存儲在該用戶的節點下，包括用戶所做的評論（與評論所關注的文章的「鏈接」）。

關於此模型的唯一棘手問題是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) 

我希望這有助於理解分層數據建模和所涉及的權衡。