私はビデオを見てGoogle Firebaseサービスからクラウドfirestoreのマニュアルを読み、私は、リアルタイムデータベースから来るから、これを理解することはできませんしています。
私は製品の別のカテゴリから自分のプロバイダを保存する念頭に置いて、このWebアプリケーションを持っています。私は何のような製品のために私が持っているプロバイダ、および最終的にはアクセスプロバイダーの情報ことを見つけるために、すべての私の製品を通じて、検索クエリを実行します。
私は、この目的のために、この構造を使用することを計画しています：
Providers ( Collection )
Provider 1 ( Document )
Name
City
Categories
Provider 2
Name
City
Products ( Collection )
Product 1 ( Document )
Name
Description
Category
Provider ID
Product 2
Name
Description
Category
Provider ID
私の質問があるので、このアプローチは、私は私が望む製品を得れば、プロバイダ情報にアクセスするための正しい方法ですか？
私はこれは私がプロバイダセクションで、そのプロバイダを検索できプロバイダのIDを使用して、リアルタイムのデータベースで可能です知っているが、Firestoreと私は確信して、可能な場合はないですか、これは正しいアプローチである場合。
firestoreにおけるこの種のデータを構造化するための正しい方法は何ですか？
あなたは存在しないことを知っておく必要があります何の構造クラウドFirestoreデータベースのための「完璧な」、「最高」または「正しい」ソリューション。最高の、正しい解決策は、あなたのニーズに適合し、あなたの仕事が容易になりますソリューションです。あることを念頭に置いても留めていないのNoSQLデータベースの世界では、単一の「正しいデータ構造」。すべてのデータはあなたのアプリケーションが必要とするユースケースを許可するようにモデル化されています。1つのアプリのためにどのような作品をこの手段は、他のアプリには不十分であり得ること。だから、みんなのための1つの正しい解決策はありません。NoSQLのタイプのデータベースのための効果的な構造は、あなたがそれを照会するつもりどのように完全に依存しています。
あなたのデータを構造化されている方法は、私には良いように見えます。一般的には、あなたが同じことを実現することが可能な2つの方法があります。最初のものは（あなたがすでにそうであるように）製品オブジェクト内のプロバイダの参照を保持するか、製品のドキュメント内全体のプロバイダオブジェクトをコピーすることです。この最後の技術はと呼ばれdenormalization、それがFirebaseに来るときはかなり一般的です。それ以外の場合は可能ではないかもしれないスーツクエリへのNoSQLデータベース内の重複データを、多くの場合、我々はそう。より良く理解するために、私はあなたがこのビデオを見るお勧めし、非正規化は、Firebaseデータベースと正常です。それはFirebaseリアルタイムデータベースのためだが、同じ原理がクラウドFirestoreに適用されます。
あなたは、データを複製する場合にも、必要性は心に留めておくべきことを一つのことがあります。あなたがデータを追加しているのと同じ方法で、あなたはそれを維持する必要があります。アップデート/プロバイダオブジェクトを削除したい場合は、他の言葉で、あなたはそれが存在していることをすべての場所でそれを行う必要があります。
あなたは、最適な技術、今不思議に思うかもしれません。非常に一般的な意味では、あなたがのNoSQLデータベースで参照または重複したデータを保存することが可能な最良の方法は、プロジェクトの要件に完全に依存しています。
あなたが自分自身のデータに関するいくつかの質問をする必要がありますので、重複しているか、単に参照として、それを維持したいです：
- 静的であるか、それが時間の経過とともに変化しますか？
- それがない場合、あなたは彼らの同期のすべての滞在ようにデータのすべての重複インスタンスを更新する必要がありますか？これは私も以前に言及しているものです。
- それはFirestoreに出たとき、あなたがのために最適化され、性能やコスト？
同じ時間での同期の変化や滞在にご重複データのニーズ場合は、最新のすべてのそれらの重複を保つ将来的に苦労している場合があります。これはまた、あなたはそれが各変更のために各ドキュメントの読み取りや書き込みが必要になりますよう、新鮮なすべてのそれらの文書を保つたくさんのお金を費やすことを意味するものかもしれませんします。この場合、参照のみを保持することは勝利のバリアントになります。
この種のアプローチでは、あなたは非常に少しの重複データを書き込む（ほとんどただProvider ID）。したがって、このデータを書き込むためのあなたのコードは非常に高速、非常にシンプルであることを行っていることを意味しています。データを読むときしかし、あなたは余分なデータベース呼び出しを意味し、両方のコレクションからデータをロードする必要があります。これは通常、文書の合理的な数のために大きなパフォーマンスの問題ではありませんが、間違いなく、より多くのコードと多くのAPI呼び出しを必要としません。
あなたは非常に高速であるためにあなたのクエリが必要な場合は、クライアントだけではなく、複数のドキュメントよりも、照会項目ごとに一つの文書を読むために持っているように、より多くのデータを複製することを好むしたいことがあります。しかし、あなたはまた、ローカルクライアントキャッシュに依存することができるかもしれクライアントが読む必要のあるデータに応じて、これは安くなります。
このアプローチでは、すべてのデータを複製しprovider、それぞれについてproductの文書。コードは、このデータを書き込むことを、この手段は、より複雑で、あなたは間違いなくより多くのデータは、各製品のドキュメントに1つの以上のプロバイダオブジェクトを保存しています。そして、あなたは、どのようにこれまでに各ドキュメントをそれを維持するかどうかを把握する必要があります。しかし一方で、読んでproduct今、文書はあなたについてのすべての情報与えproviderにおける文書1回の読み取りを。
これは、NoSQLのデータベースでは一般的な考慮事項です：あなたは、多くの場合、読み取りパフォーマンスとスケーラビリティ対書き込み性能とディスクストレージを検討する必要があります。
いくつかのデータを複製するかどうかのあなたの選択のために、それはあなたのデータとその特性に大きく依存しています。あなたはケースバイケースで通過ことを考える必要があります。
だから、最終的には、両方が有効なアプローチであり、どちらもそれらのことをすることは、より良い他のより適宜であることを覚えています。それはすべてあなたのユースケースがあり、どのように快適なあなたは、データを複製するこの新しい技術であるかに依存します。データ複製が速いの鍵はクラウドFirestoreまたはFirebaseリアルタイムデータベースではなく、一般的にだけでなく、読み込みです。あなたが別の場所に同じデータを追加するときはいつでも、あなたは、より高速な読み取りパフォーマンスの賛成でデータを複製しています。残念ながら見返りに、あなたは、より複雑な更新と高いストレージ/メモリ使用量を持っています。しかし、あなたはFirestoreで、Firebaseリアルタイムデータベース内の余分な呼び出しは、高価ではないことに注意してくださいにされている必要があります。余分なデータベース呼び出しに対して多くの複製データがあなたのために最適な方法は、あなたのニーズに依存し、あなたの意欲は、「定義考え方のシングルポイント」を手放すために
いくつかのFirebaseプロジェクトを終えた後、私は、データを複製する場合は、私の読み取りコードが大幅に単純になることがわかります。しかし、もちろん書き込みコードは、同時により複雑になります。それはあなたのアプリケーションに最適なソリューションを決定し、これらの2とニーズの間のトレードオフです。さらに、もっと正確に言えば、あなたはまた、既存のツールを使用して、アプリで何が起こっているかを測定することができますし、それに応じて決めます。私はそれが具体的な勧告ではなくのソフトウェア開発ということを知っています。すべては、物事を測定についてです。
いくつかのデータベース構造は、いくつかのセキュリティルールで保護することが容易なこと、また、覚えておいてください。だから、簡単に使用して固定することができるスキーマ探してみるクラウドFirestoreセキュリティルールを。
また、このことから私の答えを見てくださいポスト私はもっとについて説明してきたcollections、mapsとarraysFirestoreインチ