問題タブ [soft-delete]

次のようなテーブル構造がある場合：

ここcodeで主キーはです。

ユーザーはレコードを作成し、後でそれを削除します。ソフト削除を使用しているため、isdeletedはtrueに設定されます。次に、クエリでwhere句を使用してselectを実行しますand not isdeleted

これで、ユーザーが新しいレコードを作成しようとすると、コード「ABC」が存在しないことがわかり、再作成しようとした可能性があります。where句があるため、selectステートメントはそれを見つけられません。ただし、主キーインデックスエラーが発生します。

ユーザーがレコードを再利用できるようにする必要がありますか？ソフト削除のアイデアは、「削除された」レコードへの結合が引き続き機能するように、古いデータに対するクエリのレコードを保持することであるため、私はそうは思いません。ユーザーがコードの再利用を許可された場合、説明を変更して、履歴データの表示を変更する可能性があります。しかし、彼らがそのコードを使用するのを完全に止めるのは厳しすぎるのでしょうか？

または、完全に非表示の主キーを使用する必要があります。そうすれば、「コード」フィールドを再利用できますか？

実際にまたは物理的にレコードを削除するのではなく、レコードを論理的/ソフトに削除する（つまり、レコードが削除されたことを示すフラグを設定する）ことの利点は何ですか？

これは一般的な方法ですか？

これは安全ですか？

SQL には、カスケード削除という優れた機能が常にあります。事前に計画を立てて、何かを削除するときが来たら、BAM! これらすべての依存レコードについて心配する必要はありません。

しかし、今日では、実際に何かを削除することはほとんどタブーです。削除済みとしてフラグを立て、表示を停止します。残念ながら、依存レコードがある場合にこれを行うための確実な解決策を見つけることができませんでした。私は常にソフトデリートの複雑な Web を手動でコーディングしてきました。

私が完全に見逃したより良い解決策はありますか？

次のセットアップを使用して、Django で論理的な削除を実装しています。私は内部の Django にあまり詳しくないので、遭遇する可能性のある落とし穴についてのフィードバックをいただければ幸いです。私は QuerySet をサブクラス化するのが特に苦手です。

delete基本的な考え方は、 onの最初の呼び出しが現在の日時にMyModel変更されるというものです。1 秒で実際にオブジェクトが削除されます。( a をキャッチするには、オブジェクトに 1 つと、オブジェクトのメソッドをバイパスできるに 1 つの 2 つのオーバーライドが必要です。) デフォルト マネージャは削除されたオブジェクトを非表示にするため、削除されたオブジェクトは消え、マネージャを介して明示的に要求する必要があります。MyModeldate_deleteddeletedeleteQuerySetdeletedeleted_objects

この設定を使用するには、 、 、および を定義してDeletionQuerySetモデルにDeletionManager追加する必要があります。date_deletedobjectsdeleted_objects

ありがとう、

追伸、デフォルト マネージャからオブジェクトをフィルタリングするこの方法は、強く推奨されないことを忘れていました。

ほとんどのテーブルにテーブルの削除フラグがあるデータベースがあります。そのため、システムはアイテムをソフト削除します（たとえば、管理者以外はアクセスできなくなります）

テーブルがはるかに大きくなる数年後に私が心配しているのは、システムの全体的な速度が低下することです。

そのような影響を打ち消すために私は何ができますか。

• 削除フィールドにインデックスを付けますか？
• 削除したデータを同じ削除テーブルに移動し、削除を取り消すと元に戻しますか？
• 時間の経過とともに、データをいくつかのMySQLサーバーに分散しますか？（成長に基づく）

ありとあらゆる提案やストーリーに感謝します。

アップデート：

したがって、パーティショニングがこれの鍵のようです。ただし、パーティション化するだけでは、2つの「テーブル」が作成されます。1つは削除されたアイテムがあり、もう1つは削除されたアイテムがありません。

したがって、時間の経過とともに、削除されたパーティションは大きくなり、パーティションからのフェッチが遅くなります（時間の経過とともに遅くなります）。

速度の違いは私が心配すべきことでしょうか？ほとんどの（すべてではないにしても）データを何らかのキー値でフェッチするため（一部は検索ですが、このセットアップでは遅くなる可能性があります）

PHP Doctrine オブジェクトの 1 つを SoftDelete として機能させる場合、特定のクエリの結果に削除されたアイテムを含めることはできますか? 私が探しているのは、このようなものです...

このようなものは、削除されたレコードを除外したいほとんどのクエリに役立ちますが、(たとえば管理者に対して) 論理的に削除されたレコードを含めることができるようにしたい場合があります。SoftDelete を使用してこれを行う良い方法はありますか、またはほとんどのクエリに where 句を追加するだけでよいでしょうか?

ユーザーが特定のナビゲーションタブをクリックしたときに記録するMySQLdBのテーブルがあります。毎回、最後のエントリをソフト削除し、新しいエントリを挿入します。ソフト削除の理由は分析を目的としているため、ユーザーがどこで、いつ、何をクリックしているかを経時的に追跡できます。ソフト削除と新規エントリの比率は9：1であり、テーブルサイズは現時点では約20Kですが、急速に拡大しています。

だから私の質問は：ソフト削除エントリを削除することがこのテーブルを含むクエリを最適化するのに役立つかどうかです。現在、4つのテーブルを結合し、新しいエントリのみが必要なものが1つあります。ソフト削除の分析はバックアップコピーで実行できるため、本番環境のdBではこれらの行は必要ありません。

DeleteEvent Listener を実装して論理的な削除を試みます

public class MyDeleteEventListener : DefaultDeleteEventListener

{

}

( https://web.archive.org/web/20090209010820/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/04/08/soft-deletes.aspx )

ただし、1 対多、5 対多のリレーションシップからエンティティをソフト削除するわけではありません。誰かが解決策を持っていますか？

このソースによると、デフォルトのNHibernate DefaultDeleteEventListenerをオーバーライドしました：http：//nhibernate.info/blog/2008/09/06/soft-deletes.html

ので、私は持っています

NHIbernateセッションを構成せずに、このコードのみをテストするにはどうすればよいですか？

私は、設計者がすべてのテーブルを IsHistorical ビット列でマークすることを決定したデータベースで作業しています。適切なモデル化の考慮がなく、スキーマを変更する方法がありません。

これは、ナビゲーション プロパティとやり取りする CRUD 画面を開発する際に摩擦を引き起こしています。単純に Product を取得してその EntityCollection を編集することはできません。手動で IsHistorical チェックをあちこちに書かなければならず、気が狂いそうになります。

これまでのところ、追加が論理的に削除されているかどうかを確認するすべての手動チェックを作成したため、重複するエンティティを追加する代わりに、IsHistoric を切り替えることができるため、追加も恐ろしいものです。

私が検討した3つのオプションは次のとおりです。

1. t4 テンプレートを変更して、IsHistorical チェックと同期を含めます。

2. ObjectContext で削除と追加をインターセプトし、IsHistorical 列を切り替えてから、オブジェクトの状態を同期します。

3. AssociationChanged イベントをサブスクライブし、そこで IsHistorical 列を切り替えます。

誰もこれを経験したことがありますか、または最も痛みのないアプローチを推奨できますか?

注:はい、わかっています。これは悪いモデリングです。あなたが持っている論理的な削除に関する同じ記事を読みました。この要件に対処しなければならないのは面倒ですが、対処します。データベース内のすべてのナビゲーション プロパティに対して同じコードを記述せずに、論理的な削除を処理する最も簡単な方法が欲しいだけです。

注＃2 LukeLedの答えは技術的には正しいですが、あなたを本当に悪い貧乏人のORM、グラフのないパターンに強制します。問題は、「削除された」オブジェクトをすべてグラフから取り出し、それぞれに対して Delete メソッドを呼び出す必要があるという事実にあります。それは、手動の儀式的なコーディングをそれほど節約するつもりはありません。手動の IsHistoric チェックを記述する代わりに、削除されたオブジェクトを収集してそれらをループ処理しています。