Asp.net Mvc でカード管理アプリケーションに取り組んでいます。Fluent Nhibernate を ORM および Sql Server 2008 として使用しています。
ユーザーがデータを削除することを選択した場合、実際にはデータを削除しないことを検討しています。
私の質問は、それを行うための最良の方法は何ですか?また、これの結果(パフォーマンス、DBサイズ)は何ですか?
データベースのいくつかの重要なテーブルには、数千のレコードが含まれている場合があります。
前もって感謝します。
私が現在働いている場所と以前のポジションでは、アイデアは常に記録を中心に据えられていDeletedDateましDeletedByた。そうすれば、情報を取得するときはいつでも、除外してレコードのみを取得できますDeletedDate == null。
この方法では、誰がいつデータを削除したかを追跡する方法も提供されますが、DeletedDateを null にリセットすることで削除を「元に戻す」こともできます。
パフォーマンスとデータベースのサイズに関しては、SQL Server は数百万行のデータを処理できる以上の能力を備えているため、あまり心配する必要はありません。
パフォーマンスが非常に重要で、アプリケーションの速度が低下していることに気付いた場合は、削除されたデータを別のバックアップ データベースに簡単にアーカイブできます。
データを長期間保持することに煩わされない場合は、データベース内DeletedDateの 1 年以上前のものをすべて定期的に削除できます。
特に外部キーが関係している場合、これが良い考えだとは思いませんでした。これにより、実際には必要以上に複雑になる可能性があります。そして、削除されたが実際には削除されていないレコードのアイデアが好きではありませんでした。これは面倒です、IMO。
削除された行を保持したい場合は、それらを何らかのアーカイブまたは履歴テーブルに入れることをお勧めします。そうすれば、必要に応じて将来の分析のためにそれらを保持し、必要に応じて後で元に戻すことができます。
データベースのサイズは実際には問題ではありません。"数千" のレコードは、SQL Server では意味がありません。私たちの製造データベースでは、いくつかのテーブルに何億もの行があります。パフォーマンスは優れています。
SQL Server 2008 では、削除された行を非常にうまく処理できる変更データ キャプチャを利用できます。
I would make after delete trigger (it also has some performance penalty) and insert deleted rows in archive table. Then its possible to partition/data compress that archive table (if using enterprice version of SQL Server).
Archive table would look just like base table, except have some additional ID column and i would also put deletion date and user name who deleted data.