2016-07-30 5 views
0

返信できる投稿があるとしたら、これはより優れた構造ですか?火災基地データではどれくらい平らになっていますか?

1)

posts 
    908239409234 
     postText: "Whats up peeps?" 
     replies: 
      09283049830294: true 
      a9s0dif09iasd9: true 

replies 
    09283049830294 
     text: "Nm breh" 
     imageURL: nil 
    a9s0dif09iasd9 
     text: "Nm breh" 
     imageURL: nil 

または2)

posts 
    908239409234 
     postText: "Whats up peeps?" 
     replies: 
     09283049830294 
      text: "Nm breh" 
      imageURL: nil 

     a9s0dif09iasd9 
      text: "Nm breh" 
       imageURL: nil 

私はあなたが平坦化をサポートするためにどこか別の場所に保存された記事への参照を格納している#1のように見えるのデータベースのように多くの例を参照してください、私それができるのであればオプション2に行くのではないという利点はありませんか?

ユーザーが投稿に参加している場合、投稿はuidになり、「返信」の下にautoIDが追加されます。

TL; DR、もっと面白いと思われる方法や、より効率的で、少ない情報で検索する必要がある方がよいでしょうか?オプション2に行かない理由はありますか?

答えて

1

私は同行しません。 2. その理由は、 1 IDに基づいて返信データを取得するためにクエリを実行する必要があります。 firebaseを使うと、より多くの情報を書いて、少なく読むことが常に良いです。

+1

これは私が思ったものです。私はちょうどあなたが#1を奨励している人々の多くの例を見てきましたので、クエリに要するものを過大評価していたかどうかはわかりませんでしたが、もちろん#2は私にとっても意味があります。ありがとう –

0

これは、ある時点で返信を参照するかどうかによって異なります。返信があなたの投稿だけに関連し、それ以上のものでない場合、返信を取得する必要がないため、オプション2が最適です。しかし、たとえば、一部のユーザーに関連する返信をクエリするより複雑な機能を使用する場合は、オプション1として各返信への参照を格納する方が良いでしょう。これは、いくつかの点では、子や孫などが多すぎるためノードを取得するには時間がかかりすぎるため、データベースを均等にして高速にフェッチする必要がありました。私は慎重にあなたのアプリのアーキテクチャについて考えることをお勧めします。

+0

私は、オプション1対2についての私の主な心配はデータ使用量だと思う。応答ノードに10,000個の返信が格納されている場合、その特定のUIDを持っている場合は、そのリストから特定の子を取り出すことが激しいでしょうか? 私は潜在的な何千もの投稿/返信を検索する必要がなくなるようにリファクタリングしましたが、それが大きな問題でなければ、できるだけ平準化することをお勧めします。 –

+0

私のアプリケーションで私のソリューションは、より迅速にクエリを行うための参照のための参照と一緒にクエリを行う必要がある返信からいくつかのデータをコピーしましたが、詳細を問い合わせる必要がある場合は別のノードに大部分のデータを保持します。また、データの取得を延期したり、ユーザーがフォーカスしているときに取得したり、ビューにスクロールしたりするだけです。それはあなたのアプリにもかかわらずです。これは自分のウェブアプリでの自分の経験からであり、アプリには当てはまらない可能性があります。 – adbitx

関連する問題