通常、データベースに関して言えば、何も削除することはめったにありません。削除済みとしてマークすることはできますが、一般的に言えば、少なくともしばらくの間データベースに保持します。
これには多くの理由があります。それらのいくつかは合法です。特定の期間データを保持する必要がある場合があります。それらのいくつかは技術的なものです。時にはそれは単なる保護です。情報を復元する必要がある場合があります。ユーザーは、アカウントの再開を要求するか、スパム行為のためにロックされている可能性がありますが、それはアカウントが侵害され、現在復元されているためです。
古いデータは削除またはアーカイブされる可能性がありますが、これには数か月または数年かかる場合があります。
個人的には、関連するデータにステータス列 (例: 1 = アクティブ、0 = 削除済み) を付けてから、99% の確率で削除するのではなく、ステータスを変更します。
ここでは、データの整合性が別の問題になります。例を挙げましょう。
次の 2 つのエンティティがあるとします。
User: id, nick, name, email
Message: id, sender_id, receiver_id, subject, body
特定のユーザーを削除したい。彼らが送受信したメッセージをどうしますか? これらのメッセージは、他のユーザーの受信トレイまたは送信済みアイテムに表示されるため、削除できません。Message の関連フィールドを NULL に設定していますか? そのメッセージは誰かから来た (または行った) ため、たとえその人がもうアクティブでなくても、それはあまり意味がありません。
そのユーザーを削除済みとしてマークし、そのままにしておいたほうがよいでしょう。これにより、このような状況や同様の状況への対処がはるかに簡単になります。
また、フォーラムのスレッドなどについても言及しています。それらは他のコンテンツに関連するコンテンツであるため (たとえば、返信されたフォーラム メッセージなど)、それらを削除することはできません (スパムや悪用など、他の理由がない限り)。
安全かつ合理的に削除できる唯一のデータは、子データです。これが、集約と構成の実際の違いです。上記のユーザーとメッセージの関係は集約です。コンポジションの例は、家と部屋です。家を削除すると、すべての部屋が移動します。部屋はハウスなしでは存在できません。これは構成であり、エンティティ関係の用語では、親子関係です。
しかし、(私の経験では) 構成よりも集約のインスタンスの方が多いため、問題は次のようになります: そのデータをどうするか? 削除してはいけないものを削除せずに、誰かの痕跡をすべて削除することは非常に困難です。それらを削除済み、ロック済み、または非アクティブとしてマークし、そのように処理してください。