私は、mongodbとNoSQLのデータ設計全般に少し慣れていません。
非正規化されたデータを持つmongodbデータベースを構築しています。たとえば、私の「ユーザー」ドキュメントには0人以上の「Article」ドキュメントへの参照（IDのみ）が含まれ、私のArticleドキュメントには0人以上のユーザーへの参照が含まれています。
リポジトリパターンを使用しているため、データアクセス層のどの部分も記事とユーザーについて認識していません。すべてのドキュメントが互いに整合していることを確認するために、コードのどこをチェックする必要がありますか？DALのユーザーコードにチェックを行わせるだけでよいですか？
すべてが一貫しているかどうかを確認するために、データ整合性スクリプトを時々実行するのは良い考えですか？
これは、リポジトリパターンに関するMicrosoftの記事です。その文書から：
リポジトリを使用して、データを取得してエンティティモデルにマップするロジックを、モデルに作用するビジネスロジックから分離します。
いくつか質問があります。
すべてのドキュメントが互いに整合していることを確認するために、コードのどこをチェックする必要がありますか？
上記のステートメントに基づいて、このロジックがリポジトリに属していることは明らかだと思います。これらのオブジェクト間の関係は「ビジネスロジック」の層にのみ存在し、データベースはこれらのタイプのルールを適用できません。
DALのユーザーコードにチェックを行わせるだけでよいですか？
どうして彼らはできたのでしょうか？リポジトリの作成者は、DALユーザーです。MongoDBの場合、基本的にDALがドライバーです。
何らかの形式のトランザクションで複数の書き込みをラップするラッパーをドライバーに書き込むことができます。しかし、これを書く必要があります。MongoDBにはトランザクションの概念がありません。
すべてが一貫しているかどうかを確認するために、データ整合性スクリプトを時々実行するのは良い考えですか？
結局のところ、リポジトリを作成する人は誰でも、データの整合性に責任を持つことになります。このようなスクリプトは便利かもしれませんが、それは間違いなく多くのCPUサイクルを消費します。
N：Mマッピングに関する私の提案は、これら2つの同期を維持するために必要な複数の書き込みを処理するためのいくつかの基本ブロックの構築を開始することです。1つのアイデアは、変更をキューに入れ、バックグラウンドジョブに更新を行わせることです。これにより、複数の書き込みやロールバックによって不正なデータが発生することを心配する必要がなくなります。