データベース：レコードを削除するかどうか
これについて疑問に思っているのは私だけではないと思います。通常、データベースの動作について何を練習していますか？データベースからレコードを物理的に削除しますか？または、レコードがアクティブまたは非アクティブであることを示すために、レコードに「削除済み」フラグまたはブール列でフラグを立てる方が良いでしょうか？
データベースの実際の内容に依存します。セッション情報を保存するためにそれを使用している場合は、セッションの有効期限が切れた（または閉じられた）ときにすぐにそれを消去してください。実用的な目的のために実際に再び使用することはできません。
基本的に、あなたが自問する必要があるものは、この情報を復元する必要があるかもしれませんか？ SOで削除された質問と同様に、削除を積極的に許可しているため、「削除済み」とマークする必要があります。また、多くの余分な作業なしで、ユーザーを選択するためにそれを表示するオプションもあります。
データの完全な復元を積極的に求めていないが、監視（または同様の）目的のためにデータを保持したい場合。集計スキームを（もちろん可能な限り）把握し、それを別のテーブルに追い出すことをお勧めします。これにより、プライマリテーブルで「削除された」データが消去されるだけでなく、セカンダリテーブルが監視目的に最適化された状態に保たれます（または、思いついたことは何でも）。
時間データについては、以下を参照してください： http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/
削除フラグを使用する長所：
- 必要に応じて後でデータを取得できますが、
- 削除操作（フラグの更新）は、実際に削除するよりもおそらく高速です
削除フラグを使用することの短所：
AND DeletedFlag = 'N'SQLのどこかに- すべてのがらくたの中から関心のある行を見つけるためのデータベースの速度が遅い
- 最終的には、とにかく本当に削除したいと思うでしょう（システムが正常であると仮定します。そのレコードが10年前で、元の作成から4分後に「削除」された場合はどうですか）
- 自然なキーを使用できないようにすることができます。自然キーを持つ1つ以上の削除された行と、同じ自然キーを使用する実際の行がある場合があります。
- 実際にデータを削除することになっているのは、法的/コンプライアンス上の理由がある場合があります。
すべての投稿を補完するものとして...
ただし、レコードをマークする予定がある場合は、アクティブなレコードに対してビューを作成することを検討してください。これにより、SQLクエリのフラグを記述したり忘れたりすることを防ぎます。目的にも役立つと思う場合は、非アクティブなレコードのビューも検討してください。
このスレッドを見つけてうれしいです。私も、この問題について人々がどう考えているのかと思っていました。私は多くのシステムで約15年間「削除済みとしてマーク」を実装しました。ユーザーが何かを誤って削除したと言うときはいつでも、再作成またはバックアップから復元するよりも、削除されていないものとしてマークする方がはるかに簡単です。
PostgresqlとRuby on Railsを使用して、2つの方法のいずれかでこれを実行できるように見えます。修正Railsまたは、ondeleteトリガーを追加し、代わりにpl/pgsql関数を実行して削除済みとしてマークします。
パフォーマンスヒットについては、削除されたアイテムの数が少ないだけでなく、削除されたアイテムが少ない場合の大きなテーブルでのEXPLAIN-ANALYZEの結果を見るのも興味深いでしょう。
私が見つけた時間の経過とともに使用されるシステムでは、新しいユーザーは誤って削除するような愚かなことをする傾向があります。そのため、ある人が新しいポジションにいる場合、経験がない場合を除き、そのポジションにいる人のすべてのアクセス権があります。誤って何かを削除し、すぐに回復できるようになると、全員がすばやく仕事に戻ることができます。
しかし、誰かが言ったように、何らかの理由でその特定のキーを戻す必要がある場合があり、その時点で本当に削除してからレコードを再作成する必要があります（削除を取り消してレコードを変更します）。
個人データが関係する場合は、いずれの場合も法的問題があります。それはあなたがどこにいるのか（またはデータベースがどこにいるのか）、そして使用条件が何であるかによって大きく左右されると思います。
場合によっては、システムからの削除を依頼されることがあります。その場合、完全な削除が必要です（または、少なくともすべての個人情報を消去する）。
個人情報が関係する場合は、いずれかの方法で戦略を採用する前に法務部門に確認します。
それらを削除済みとしてマークしますが、実際には削除しません。しかし、たまにすべてのジャンクを一掃してアーカイブするため、パフォーマンスを損なうことはありません。
データベースのアクセスが遅くなる「休止」レコードが心配な場合は、それらの行を「アーカイブ」テーブルとして機能する別のテーブルに移動することをお勧めします。
ユーザーが入力/管理するデータの場合、説明したフラグ方式を使用し、ユーザーに「ゴミ箱を空にする」インターフェースを与えて、必要に応じてアイテムを実際に削除しました。