0

私の現在のプロジェクトでは、(私にとって) かなり変わった要求がありました。クライアントは、データベース テーブルからレコードを物理的に削除するのではなく、すべての削除手順でフラグをマークすることを望んでいます。一見するととても簡単に見えます。私はちょうど変更を持っています

public void DeleteRecord(Record record)
{ 
    record.DeleteAndFlush();
}

public IList GetAllRecords()
{
    Record.FindAll().ToList();
}

に

public void DeleteRecord(Record record)
{ 
   record.Deleted = true;
   record.UpdateAndFlush();
}

public IList GetAllRecords()
{
    Record.FindAll().Where(x=>x.Deleted==false).ToList();
}

でも、少し時間ができたので、もう一度考えてみます。この小さな変更がカスケード設定に大きな問題を引き起こすことがわかりました。私は Active Record ビジネスにかなり慣れていないので。すべての CascaeEnum.Delete を CascadeEnum.SaveUpdate に単純に変更することはできません。だから、私はここでいくつかの入力を探しています。

1) マークは物理的な要件ではなく、一般的なフラグですか?

2) 質問 1 に対する答えが「はい」の場合、NHibernate にはこれを処理するための組み込み機能があると思います。この種の問題に対する正しいアプローチを教えてもらえますか?

ご意見ありがとうございます。

4

3 に答える 3

2

これは非常に一般的で、「ソフト削除」と呼ばれます。これがNHibernate用のこれの実装です。

于 2009-09-29T01:25:48.910 に答える
2

これはソフト削除と呼ばれ、非常に一般的です。ベスト プラクティスについてはいくつかの議論があります - この最近のブログ投稿をチェックしてください: http://ayende.com/Blog/archive/2009/08/30/avoid-soft-deletes.aspx

于 2009-09-29T01:24:41.550 に答える
1

これは比較的一般的なリクエストであり、（少なくとも）2つの理由で実装されることがあります。

  1. 監査と履歴-行を物理的に削除するのではなく削除済みとしてマークすることは、必要に応じて情報を引き続き利用できることを意味します（たとえば、誤って間違った顧客を削除した場合の情報の回復を含む）。
  2. パフォーマンス-このメソッドを使用して削除をバッチ処理するシステムを確認したので、静かな時間に物理的に実行できます。これが最新のDBMSで必要かどうかは疑わしいですが、ひどく過負荷のシステムでカスケード削除を回避したい場合は、過去にどのように必要だったかがわかります（もちろん、このようなシステムで実行するべきではありません。そもそも）。Oracle 8では、このような方法で列を削除でき、要求された場合にのみ物理的に削除されるこのような機能が導入されました。情報が完全に削除されていなくても、列をまったく使用できませんでした。列の許可された削除は、行の削除よりも集中的ですが、それでも役立つ場合があります。
于 2009-09-29T01:27:29.533 に答える