0

SQL Serverでは、テーブルの親行を削除するときにカスケードで削除を使用できることを知っていますが、SQL Serverでカスケードで削除するよりも、アプリケーション（リポジトリ）でこのロジックを実装する方がよい場合があります。

だから私は2つの質問があります。まず、SQL Serverの削除カスケードで使用しない場合、EntityFrameworkでこの状況を解決する方法。

  1. ユーザーAは、親レジスタとその子をコンテキストに追加します
  2. ユーザーBは、親レジスタに新しい子を追加します。したがって、ユーザーAにはこの子がコンテキストに含まれていません
  3. ユーザーAは、自分のコンテキストにロードされている親とすべての子を削除します。これらの子には、ユーザーBによって追加された新しい子は含まれません。

実際には、問題はありません。ユーザーAが親を削除しようとすると、参照整合性の例外が発生し、すべての子をロードして再試行する必要があります。

これはSQLServerにとって余分な作業です。これは、ユーザーAにすべてのレジスタを再度送信する必要があるためです。

SQL Serverのカスケードで削除を使用する場合、この問題は存在しないため、適切なオプションだと思います。

したがって、私の2番目の質問は、SQL Server（または他のデータベース）の削除カスケードで使用するのは良い考えですか、それともビジネスロジック（リポジトリ）でこのケースを実装する方が良いですか？

ありがとう。

4

1 に答える 1

1

それは個人的な好みの問題です-私は両方のオプションについて有効な議論を聞きます。

あなたにとってより明白で、より理解しやすいものは何ですか？

  • 自動マジック削除を希望しますか？次に、ON DELETE CASCADE

  • または、これらの状況を完全に制御して、いつ、何が削除されるかを正確に把握することをお勧めしますか？次に、独自のカスタムコードで実装します

正しいことも悪いこともありません。「良い」または「悪い」ということはありません。それは、あなた自身の個人的な好みと、コードをより快適に感じる方法に関するものです。

于 2012-12-16T12:43:33.243 に答える