MongoDBの正規化、外部キー、および参加
何日もMongoDBを深く掘り下げる前に、MongoDBに飛び込むべきかどうかについて、かなり基本的な質問をしたいと思いました。私は基本的にnosqlの経験がありません。
ドキュメントデータベースの利点のいくつかについて少し読んだことがありますが、この新しいアプリケーションでは本当に素晴らしいものになると思います。多くの種類のオブジェクト（多くのm-to-m関係）およびサブクラスに対してお気に入りやコメントなどを行うのは常に面倒です-対処するのは一種の苦痛です。
また、非常にネストされており、15種類のテーブルよりもはるかに優れたドキュメントに変換されるため、SQLで定義するのが面倒な構造もあります。
しかし、私はいくつかのことについて混乱しています。
データベースをまだ標準化しておくことが望ましいですか？複数のレコードを更新したくありません。 MongoDBのデータベースの設計に人々はどのようにアプローチしていますか？
ユーザーが本をお気に入りにし、この選択がユーザー文書にまだ保存されているが、その後本が削除されるとどうなりますか？外部キーなしで関係はどのように切り離されますか？自分ですべてのリンクを手動で削除する必要がありますか？
存在しない本をユーザーがお気に入りにして、それをクエリした場合（何らかの結合）はどうなりますか？ここでフォールトトレランスを行う必要がありますか？
MongoDBはサーバー側の外部キー関係をサポートしていません。正規化もお勧めできません。可能であれば、親オブジェクト内に子オブジェクトを埋め込む必要があります。これにより、パフォーマンスが向上し、外部キーがまったく不要になります。ただし、常に可能であるとは限らないため、異なるコレクション内のオブジェクトを参照できるDBRefという特別な構造があります。 DBはオブジェクトを読み取るために追加のクエリを作成する必要がありますが、外部キー参照の種類を許可するため、これはそれほど高速ではありません。
それでも、参照を手動で処理する必要があります。 DBRefの検索中にのみ、DBRefが存在するかどうかがわかりますが、DBはすべてのドキュメントを参照して参照を探し、参照のターゲットがもう存在しない場合はそれらを削除しません。しかし、本を削除した後にすべての参照を削除するには、コレクションごとに1つのクエリが必要になると思うので、それほど難しくありません。
スキーマがより複雑な場合は、おそらくnosqlではなくリレーショナルデータベースを選択する必要があります。
MongoDBデータベースの設計に関する本もあります。 MongoDBのドキュメントデザイン
[〜＃〜] update [〜＃〜]上記の本はもう利用できませんが、MongoDBの人気のために他にもたくさんあります。そのようなリンクは変更される可能性が高いため、すべてをリンクするわけではありません。Amazonでの単純な検索では複数のページが表示されるため、一部を見つけるのに問題はありません。
詳細と例については、MongoDBのマニュアルページの 「手動参照」とDBRefs を参照してください。
上記、@ TomaaszStanczak州
MongoDBはサーバー側の外部キー関係をサポートしていません。正規化もお勧めできません。可能であれば、親オブジェクト内に子オブジェクトを埋め込む必要があります。これにより、パフォーマンスが向上し、外部キーがまったく不要になります。それはそれが常に可能であるとは言えません...
Mongoは正規化を推奨していません。明確にするために、2つのデータエンティティが持つことができる2つの根本的に異なるタイプの関係について話しています。 1つでは、1つの子エンティティが親オブジェクトによって排他的にownedされます。このタイプの関係では、Mongoの方法を組み込む必要があります。
他の関係のクラスでは、2つのエンティティが独立して存在します-独立したライフタイムと関係を持ちます。モンゴは、このタイプの関係が存在しなかったことを望み、それをどのように処理するかについてイライラして沈黙しています。埋め込みは単なる解決策ではありません。正規化は推奨されません。 Mongoは、それに対処するための2つのメカニズムを提供します。 手動参照 （2つのテーブルをバインドする外部キー制約を持つキーに類似）、および DBRef （同じことを行う、少しだけ構造化された別の方法）。このユースケースでは、SQLデータベースが優先されます。