私は Mongo で REST API を作成しており、ドキュメント モデリング戦略全体に興味をそそられました。人々が最初に非正規化してから正規化する、またはその逆と言うのは、非常に意見の分かれる問題のようです。
REST API のリソース構造がドキュメント ベースのデータベースの構造にどのように影響するかを知りたいと思っています。REST api リソース構造では、Mongo の利点の 1 つに反するように見えますが、すべて (つまり、場所、テナント、トランザクション) に対して個別のコレクションを持つことはほぼ理にかなっています。
私の質問は、NoSQL (具体的には Mongo) ドキュメント データベースで REST API のリソースをどのようにモデル化するかということです。
答えは、何を最適化するかに応じて、多くの方法があるということです。一般に、ドキュメント スキーマの定義とコレクションの分離は、ドキュメントの特定のユース ケース (データをどのように使用するか) によって異なります。
覚えておくべき大きな概念の 1 つは、コレクション間の「結合」にはコストがかかるということです。基本的に、あるコレクションから外部キーを取得し、別のコレクションで他のルックアップ全体を実行しているため、非正規化は一般的にパフォーマンスに役立ちます - 一致する場合あなたのユースケース。ここで MongoDB が活躍する可能性がありますが、将来、要件が変更された場合、ドキュメント構造を大幅に変更する必要が生じる可能性があります。
2 つ目の重要な考慮事項は、MongoDB のドキュメント サイズの制限です。前回確認したときは約 16MB でした。ブログ投稿コレクションを使用した従来のブログ Web サイトの例を考えてみましょう。コメントをサブドキュメントとして保存することも、投稿ドキュメントの配列として選択することもできます。このようにして、/posts/postID の REST API を使用して、コメントなどのために他のコレクションで「結合」や検索を行うことなく、投稿ドキュメントを返すことができます。しかし、膨大な量のコメントを含む投稿がある場合、問題が発生します。その場合、コメントを別のコレクションに分離してデータを正規化する必要があります。
したがって、データベースからの取得の速度/容易さ、およびドキュメント ストレージの柔軟性 (将来のためにドキュメントのスキーマ構造を変更する必要がある場合) は、プロジェクト API を計画する際に考慮すべき 2 つの主要な考慮事項です。
ドキュメント/コレクション X をどのように使用するかを自問してください。いつそこからデータを取得する必要がありますか? 1 つのリソーステナントに「親リソース」の場所があり、場所へのアクセスが実際にテナントを必要とする唯一の場合、テナントのストレージを場所のスキーマに設計できる可能性があります。ただし、テナント自体にクエリを実行できるようにする必要がある場合は、おそらくテナントを独自のコレクションに分割する必要があります。そのため、正しい方法も間違った方法もありません。データの消費方法に基づいて計画を立ててください。
幸運を！