firebaseリアルタイムスキーマデザイン

Question

firebaseリアルタイムスキーマに2つのエンティティがあります。呼び出された注文と顧客。

これまでのところ、私は実際に私のアプリでそれらを関連付けるのではなく、関連性を示していました。現在のスキーマが見えたように：私は

/orders.json発射ますテーブル内のすべての注文を示す注文一覧ページを持っている。しかしそう

{ 
"orders" : [ 
      {"id" : 1, "name": "abc", "price": 200, "customer": "vik"} 
      ], 
"customers" : [ 
       {"cust_id" : "10", "name" : "vik", "type": "existing"} 
       ] 
} 

事実上、代わりに直接顧客名を持ちます注文は、私はcust_id属性がキーである必要があります。

これは当然のことながら、注文の不一致を心配することなく顧客属性を自由に変更できる標準的なリレーショナル・スキーマです。

しかし、私がすぐに見ているのは、注文リストテーブルに表示する20の注文がある場合、1の代わりに21の残りの呼び出しを発射することになります（注文リストを取得するために1、顧客をフェッチするために

これに関する推奨事項や基準は何ですか？

Answer 1

FirebaseはNoSQLデータベースです。したがって、リレーショナルデータベースから知る正規化のルールは必ずしも適用されるわけではありません。

たとえば、各注文の顧客名を持つことは、実際には非常に正常です。これにより、顧客レコードごとにクライアント側の参加が不要になり、コードが大幅に簡素化され、操作のスピードが向上します。もちろん、NoSQLデータベースでは通常のデータを何度も保存する必要があり、顧客レコードの更新時に複製データを更新するかどうかを検討する必要があります。

NoSQL data modelingを読んで、Firebase for SQL developersを見て、私の答えをkeeping denormalized data up to dateで読むことをお勧めします。