MongoDBにはカスケード削除はありません。アプリケーションがデータを削除すると、参照されているオブジェクト自体と削除されたドキュメントへの参照も削除されます。ただし、通常、on deleteを使用する場合 リレーショナルデータベースでは、1つの親オブジェクトが1つ以上の子オブジェクトを所有し、子オブジェクトは親なしでは意味がないという構成の場合があります。 そのような状況では、MongoDBは参照する代わりに埋め込みを推奨します 。つまり、親オブジェクトに配列を作成し、完全な子ドキュメントを独自のコレクションに保持するのではなく、その配列に配置します。そうすれば、それらは親の一部であるため、親と一緒に削除されます。
1つのフィールドに複数の値を保持することは、SQLでは絶対にやめられますが、MongoDBでは問題はありません。これは、MongoDBクエリ言語が配列や埋め込みオブジェクトを簡単に処理できるためです。配列内のサブドキュメントのフィールドにインデックスを作成することもできるため、他のオブジェクトに埋め込まれているオブジェクトを簡単に検索できます。
それでも別のコレクションのオブジェクトを参照する場合は、DBRefを使用するか、他の一意の識別子を使用することもできます（一意性は、MongoDBによって適用できる数少ないものの1つです。これを行うには、createIndexコマンドを使用して一意のインデックスを作成する ）。ただし、この場合、MongoDBは一貫性を強制しません。存在しないObjectIdを指すDBRefを作成でき、DBRefが指すドキュメントが削除されても、何も起こりません。アプリケーションは、ドキュメントを削除するときに、それを参照するすべてのドキュメントが更新されるようにする責任があります。
MongoDBでも制約を適用することはできません。 MongoDBのスキーマレスの性質により、フィールドに特定のタイプを強制することさえできません。繰り返しになりますが、アプリケーションは、mongodbに入れるデータが特定の仕様に従っていることを確認する責任があります。これを自動化したい場合は、利用可能な多くのプログラミング言語用のMongoDB用のオブジェクトリレーショナルマッピングフレームワークがあります。
すべてをまとめるには： MongoDBは、SQLデータベースほど「スマート」ではありません。それ自体ではあまり効果がありません。それは、アプリケーションによって実行するように指示されていることを実行しますが、それ以上でもそれ以下でもありません。しかし、それが非常に高速で（高価な整合性チェックがなく）、柔軟性があり（新しい機能を実装するためにデータベースを変更する必要がない）理由です。