SQL DB を作成し、整合性を調べました。ここで、これらのテーブルを mongoDB に配置したいと思い、マッピング ルールに保持しました。テーブル = コレクション、行 = ドキュメントなど。
しかし、mongoDBで次のことをどのように設定しますか:
create table pruefen
( MatrNr integer references Studenten on delete cascade,
VorlNr integer references Vorlesungen,
PersNr integer references Professoren on delete set null,
Note numeric(2,1) check (Note between 0.7 and 5.0),
primary key (MatrNr, VorlNr));
DBRef、試してみましたが、外部キーの置換ではありません。
そして、アプリケーションがその外観を引き継ぐ場合はどうなりますか?MongoDB にはカスケード削除がありません。アプリケーションがデータを削除する場合、参照されているオブジェクト自体と、削除されたドキュメントへの参照もすべて削除する必要があります。しかし、通常on delete、リレーショナル データベースで使用する場合、1 つの親オブジェクトが 1 つ以上の子オブジェクトを所有し、子オブジェクトは親なしでは意味をなさない構成のケースがあります。そのような状況では、MongoDB は を参照する代わりに埋め込むことを推奨します。つまり、親オブジェクトに配列を作成し、完全な子ドキュメントを独自のコレクションに保持するのではなく、その配列に配置します。そうすれば、それらは親の一部であるため、親と一緒に削除されます。
フィールドに複数の値を保持することは、SQL では絶対に禁止されていますが、MongoDB では何も問題はありません。これは、MongoDB クエリ言語が配列や埋め込みオブジェクトを簡単に操作できるためです。配列内のサブドキュメントのフィールドにインデックスを作成することもできるため、他のオブジェクトに埋め込まれているオブジェクトを簡単に検索できます。
別のコレクションからオブジェクトを参照したい場合は、DBRef を使用するか、他の一意の識別子を使用することもできます (一意性は、MongoDB によって強制できる数少ないものの 1 つです。そのためには、一意のインデックスを作成しますcreateIndex コマンドを使用します)。ただし、この場合、MongoDB は一貫性を強制しません。存在しない ObjectId を指す DBRef を作成できます。DBRef が指すドキュメントが削除されても、何も起こりません。アプリケーションは、ドキュメントを削除するときに、それを参照するすべてのドキュメントが更新されるようにする責任があります。
制約は、MongoDB によっても適用できません。MongoDB のスキーマレスな性質により、フィールドに特定の型を強制することさえできません。繰り返しになりますが、アプリケーションは、mongodb に入れるデータが特定の仕様に従っていることを確認する責任があります。これを自動化したい場合は、MongoDB 用のオブジェクト リレーショナル マッピング フレームワークが利用可能な多くのプログラミング言語で利用できます。
まとめとして、MongoDB は SQL データベースほど「スマート」ではありません。それ自体ではあまり効果がありません。アプリケーションから指示されたことを実行しますが、それ以上でもそれ以下でもありません。しかし、それが非常に高速 (コストのかかる一貫性チェックがない) であり、柔軟性がある (新しい機能を実装するためにデータベースを変更する必要がない) 理由です。
リレーショナル データベースの優れた点の 1 つは、データベース内でデータの一貫性を維持するのに非常に優れていることです。その方法の 1 つは、外部キーを使用することです。外部キー制約とは、別のテーブルの列の値を持つ外部キー列を持つ列を持つテーブルがあるとしましょう。ではMongoDB、外部キーが保持されるという保証はありません。データがそのように一貫していることを確認するのは、プログラマ次第です。これは の将来のバージョンで可能になるかもしれませんMongoDBが、現在、そのようなオプションはありません。外部キー制約の代替手段はデータの埋め込みです。