Firebaseのデータ構造とURL

Question

私はFirebaseとnosqlの新機能ですので、SQLへの参照を使用してください。 私の質問はfirebaseのデータをどのように構造化するかです。

firebaseでは、mysqlの「新しいfirebase」=「new Database」または「table」を意味しますか？

私のリアルタイムWebアプリでは、ユーザーとコメントがあります。 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 

をしかし、記事のように、第3のエンティティがある可能性が高い、とユーザーはそれぞれ（上のコメントしていること他の）記事。

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つの画面に必要な情報を得るために必要なルックアップの数です。

1. （ARTICLESノードからの）物品自体を読む
2. （ARTICLE_USER_COMMENTノードからの）コメントについての情報を読む
3. （コメントノードからの）コメントの内容を読む

必要に応じて、USERSノードも参照する必要があります。

Firebaseには、特定の記事または特定のユーザに一致するARTICLE_USER_COMMENTの要素だけを選択できるWHERE句の概念はありません。

実際には、構造をマッピングするこの方法は使用できません。 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) 

あなたは、私たちは、この最後の例ではコメントや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) 

私は、これは階層的なデータ・モデリングと関係するトレードオフを理解するのに役立ちます願っています。