ファイアベース - データベース構造の効率とフラット性

Question

私のアプリの基本的な流れは、ユーザーが自分の友達に投稿を送り、友人がその投稿への返信を投稿できるようにすることです。私は2つのオプションを持っている

は、私のような感じ：

1) 
users 
    9308490384 
    postsInitiated 
     029309jf: true 
    InitiationsInvitedTo 
     lsfjijl39j390jf: true 
     lkajls;dkfj3ijl3f: true 
initiations: 
    029309jf 
     timestamp: 293084093 
     picURL: picture.com 
     replies: 
      abc123: true 
      edf234: true 
    lsfjijl39j390jf 
     etc.. 
replies: 
    abc123   
     picURL: picture.com 
     posterUID: lsjdflkjk 

2）

users 
    9308490384 
    postsInitiated 
     029309jf: true 
    InitiationsInvitedTo 
     lsfjijl39j390jf: true 
     lkajls;dkfj3ijl3f: true 
initiations: 
    029309jf 
     timestamp: 293084093 
     picURL: picture.com 
     replies: 
     abc123   
      picURL: picture.com 
      posterUID: lsjdflkjk 

両者の違いは、 "回答" の下のイニシエーションの下にあります。第一の選択肢は

abc123: true 

のような応答のリストを持っているし、私はpicURL/posterUIDを見つけるために、回答ビットを検索するABC123キーを使用すると思います。

2番目のオプションは、[Initiation's replies]ビットの応答データをリストします。

ユーザーメッセージノードと「すべてのメッセージ」アレイを持つチャットアプリケーションが多数あり、ユーザーメッセージノードのメッセージのUIDSを使用してすべてのメッセージノードを検索します。

このケースでは、イニシエーションの下に返信情報をリストするだけで問題はありますか？私は間違いなく "返信"ノードを指すことでそれをさらに平坦化することができましたが、これは不要です。そんなに平らにする必要はありませんが、どこでもほとんどの場合、できるだけデータを平坦化することをお勧めします。

Answer 1

アプローチ1の利点は、データを1か所に書き込むだけで済みます。したがって、データを書き込むコードが簡単になります。また、キーへのデータ複製量も削減されます。

アプローチ2の利点は、ツリーの1つの場所からのみデータを読み込む必要があることです。したがって、データを読み取るコードが簡単になります。それはまた、小さなパフォーマンスの利点がありますが、そのモデルを選択する理由であってはなりません。

特定の最良の解決策はありません（正直言って、ほとんどありません）。それはあなたのアプリとそのユースケースによって異なります。あなたがアプリケーションを構築しているとき（そしてユーザーがそれを使って作業を始めるとき）、ユースケースを明らかにする可能性が高いので、どちらのアプローチでも使い始めることができます。