必要に応じて、コンテンツの保存と分類を行います。プラクティスについて説明します。適切な構造のデータベースを構築するには、事前の綿密な計画が必要です。データの保存方法と後で取得する方法をあらかじめ計画し、このプロセスをできる限り簡単にしておくことが最も重要です。オブジェクトとして保存されます。ツリーであると考えることができます。データベースとは異なり、テーブルやレコードはありません。構造のノードとして、関連するキーと一緒に保存されます。メソッドによって提供されるキーを使用することもできます。バイトにおさめる必要があります。含めることはできません。制御文字を使用することはできません。アプリケーションについて考えてみましょう。エントリがあるとします。型に対応する特定のネイティブ型で表現することで、より保守しやすいコードを記述できます。レベルの深さまでデータをネストできるため、これがデフォルトの構造であると思ってしまうかもしれませんが、そうではありません。データベース内の特定の場所にあるデータをフェッチすると、その子ノードもすべて取り込むことになります。データベース内のノードの読み取りアクセス権や書き込みアクセス権をあるユーザーに付与すると、そのノードの下位にあるすべてのデータへのアクセス権もそのユーザーに付与することになります。したがって、実際には、データ構造をできる限りフラットにしておくのが最善です。ネストされたデータが良くない理由の例として、次のように多重にネストされた構造について考えてみましょう。}}このようなネストされた設計でデータを反復処理するのは厄介な作業です。ツリー全体(すべてのメンバーとメッセージも含む)をクライアントにダウンロードしなければいけません。データ構造を平坦化するデータを複数のパスに分割する(非正規化とも呼ばれます)と、必要に応じて、データを個別の呼び出しで効率的にダウンロードできます。この平坦化された構造について考えてみましょう。ルーム一覧またはルームを表示するためのメタデータをすばやくフェッチできます。応答性と速度が損なわれることはありません。スケーラブルなデータを作成するアプリの構築では、リストのサブセットをダウンロードできるようにすると良好な結果が得られることがよくあります。この傾向は、リストに何千件ものレコードが含まれている場合に特によく見られます。この関係が静的かつ単方向の場合は、子オブジェクトを親の下にネストするだけです。この関係がより動的なときは、データの非正規化が必要になる場合があります。多くの場合は、データの取得で説明しているように、データのサブセットを取得するクエリを使用して、データを非正規化できます。これでもまだ不十分な場合があります。ユーザーとグループとの双方向の関係について考えてみましょう。ユーザーはグループに所属でき、グループはユーザーのリストから構成されます。ユーザーの所属先のグループを決定することになると、状況が複雑になります。必要なのは、ユーザーが所属するグループをリストして、それらのグループのデータだけをフェッチする的確な方法です。この場合、グループのインデックスが大変役に立ちます。レコードの下とグループの下の両方に関係を保存した結果、一部のデータが重複していることに気が付かれたと思います。か所で更新を行う必要があります。これは、双方向の関係に必要な冗長性です。メンバーシップをすばやく効率的にフェッチできます。あることを確認するだけで、キーがないかのチェックが済むようにしています。インデックスはデータのクエリやスキャンを実行するよりも迅速かつ効率的です。ライセンスにより使用許諾されます。ライセンスにより使用許諾されます。サイトのポリシーをご覧ください。関連会社の登録商標です。