データベース：レコードを削除するかどうか

これについて不思議に思っているのは私だけではないと思います。通常、データベースの動作について何を実践していますか？データベースからレコードを物理的に削除しますか？または、「削除済み」フラグまたはブール列でレコードにフラグを立てて、レコードがアクティブまたは非アクティブであることを示す方が良いでしょうか？

それは間違いなくあなたのデータベースの実際の内容に依存します。これを使用してセッション情報を保存している場合は、セッションの有効期限が切れた（または閉じられた）ときにすぐにワイプしてください。そのごみが滞るのは望ましくありません。実際の目的で再び使用することはできません。

基本的に、あなたが自問する必要があるもの、私はこの情報を復元する必要がありますか？SOで削除された質問と同様に、削除の取り消しを積極的に許可しているため、それらは間違いなく「削除済み」とマークされているはずです。余計な手間をかけることなく、ユーザーを選択するために表示するオプションもあります。

データを完全に復元しようとはしていませんが、監視（または同様の）目的でデータを保持したい場合。（もちろん可能な限り）集計スキームを理解し、それを別のテーブルに振り分けることをお勧めします。これにより、プライマリテーブルが「削除された」データをクリーンな状態に保つだけでなく、セカンダリテーブルを監視目的（またはあなたが考えていたもの）に最適化された状態に保ちます。

時間的データについては、http：//talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/を参照してください。

削除フラグを使用する利点：

1. 必要に応じて、後でデータを取り戻すことができます。
2. 削除操作（フラグの更新）は、実際に削除するよりもおそらく高速です

削除フラグの使用の短所：

1. AND DeletedFlag = 'N'SQLのどこかを見逃すのは非常に簡単です
2. データベースがすべてのがらくたの中で興味のある行を見つけるのが遅い
3. 最終的に、とにかく本当にそれを削除したいと思うでしょう（システムが成功したと仮定します。そのレコードが10年前で、最初に作成されてから4分後に「削除」された場合はどうでしょうか）。
4. 自然キーを使用できなくなる可能性があります。自然キーを含む1つ以上の削除された行と、同じ自然キーを使用したい実際の行がある場合があります。
5. 実際にデータを削除しようとしているのには、法的/コンプライアンス上の理由があるかもしれません。

すべての投稿を補完するものとして...

ただし、レコードにマークを付ける予定がある場合は、アクティブなレコードについて、ビューを作成することを検討することをお勧めします。これにより、SQLクエリでフラグを書き込んだり、忘れたりする必要がなくなります。非アクティブレコードのビューも目的に役立つと思われる場合は、それも検討する必要があります。

このスレッドを見つけてよかったです。私もこの問題について人々がどう思っているのかと思っていました。私は、「削除済みとしてマーク」を約15年間、多くのシステムに実装してきました。ユーザーが何かを誤って削除したと言うときはいつでも、それを再作成したり、バックアップから復元するよりも、削除されていないものとしてマークする方がはるかに簡単でした。

postgresqlとRuby on railを使用していますが、これは、レールを変更するか、ondeleteトリガーを追加して、代わりに削除済みとしてマークするpl / pgsql関数を実行する2つの方法のいずれかで実行できるようです。私は後者に傾いています。

パフォーマンスへの影響については、削除されたアイテムが少ないだけでなく、削除されたアイテムが多い場合の大きなテーブルでのEXPLAIN-ANALYZEの結果を確認すると興味深いでしょう。

長い間使用してきたシステムで、新しいユーザーは誤って物事を削除するなど、ばかげたことをする傾向があります。したがって、新しい位置にいる人は、経験がゼロでない限り、その位置にいた人のすべてのアクセス権を持っています。誤って何かを削除して迅速に回復できると、全員がすぐに作業に戻ります。

しかし、誰かが言ったように、いくつかの理由でその特定のキーが必要になる場合があります。その時点で、本当にそのキーを削除してから、レコードを再作成する必要があります（削除を取り消してレコードを変更する場合）。

個人データが関係する場合は、いずれにせよ法的な問題もあります。それはあなたがどこにいるのか（またはデータベースがどこにあるのか）と使用条件が何であるかに大きく依存すると思います。

場合によっては、システムからの削除を要求できることがあります。その場合、完全削除が必要です（または少なくともすべての個人情報を消去する必要があります）。

個人情報が含まれる場合は、どちらの方法でも戦略を採用する前に、法務部門に確認します。

私はそれらを削除済みとしてマークし、実際には削除しません。ただし、たまにすべてのジャンクを一掃してアーカイブするので、パフォーマンスが低下することはありません。

データベースのアクセスが遅くなる「休止」レコードが心配な場合は、それらの行を「アーカイブ」テーブルとして機能する別のテーブルに移動することができます。

ユーザーが入力/管理するデータの場合、私はあなたが説明するフラグメソッドを使用し、ユーザーが「ゴミ箱を空にする」インターフェイスを提供して、アイテムを選択した場合は実際にアイテムを削除しました。