web-dev-qa-db-ja.com

Firebaseのデータ構造とURL

私はFirebaseとnosqlの初心者であるため、sqlへの参照を使用してください。だから私の質問は、firebaseでデータをどのように構造化するのですか？

Firebaseでは、mysqlのすべての「new firebase」=「new database」または「table」を意味しますか？

リアルタイムWebアプリの場合、ユーザーとコメントがあります。 mysqlでは、ユーザーとコメントテーブルを作成し、それらをリンクします。

Firebaseでこれをどのように構成しますか？

data-structuresnosqlfirebase
55
vzhen

ユーザーとコメントがある場合は、次のように簡単にモデル化できます。

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. 記事自体を読む（記事ノードから）
  2. コメントに関する情報を読む（ARTICLE_USER_COMMENTノードから）
  3. コメントの内容を読む（COMMENTSノードから）

ニーズによっては、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)

この最後の例で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)

これが、階層的なデータモデリングとそれに伴うトレードオフの理解に役立つことを願っています。

144
Frank van Puffelen