物理削除と論理削除、どっちがいいの？

質問

データベースを使用したシステムを構築する際に論理削除を
多用していますか？ 物理削除を行うと、他のテーブルから
参照できなくなって面倒な場合も多いと思います。しかし
論理削除の場合、例えばテーブルAのレコードAに対して、
テーブルBのレコードが１つのみ対応するという場合、論理削除
で削除データを残すとすると、テーブルBの項目にAの主キーを
持つとして、そのキーをUNIQUEにすることができませんよね。
その辺りの処理をアプリ側でやるというのも、どうもバグの温床に
成りかねない気もします。

システム構築の際に、物理削除が良いのか、論理削除が良いのか、
どちらがBetterな選択なのでしょうか？

回答No.2

DocumentServer21 · ベストアンサー

以前、基幹系システムの開発や設計に携わっていました

NO1さんと同じく、論理削除とは「実データは削除しないが、削除フラグを立てるなどで
システム上削除されたデータとして扱う」と仮定して回答します

＞システムを構築する際に論理削除を多用していますか？
ユーザーからデータを残すよう依頼があった場合に、論理削除で処理していました
対象データは、金額や取引が記録されているデータや、後から追跡する可能性があるデータが多かったです。
（受発注データや売上仕入データなど）

＞システム構築の際に、物理削除が良いのか、論理削除が良いのか、
楽なのは物理削除ですね（特にテスト）。ただ、どちらを選択するかはシステム要件によります。
どちらを選んでも、データの整合性を保つようシステムを設計することが大切です

＞物理削除を行うと、他のテーブルから参照できなくなって面倒な場合も多い
論理削除でも物理削除でも、「削除されたデータは参照されない」が
正しいシステムだと思います。

＞論理削除で削除データを残すとすると、テーブルBの項目にAの主キーを持つとして、
＞そのキーをUNIQUEにすることができません
これは意味がよく分からないのですが、こういった不整合は設計でつぶす必要があると思います

論理削除でもしっかり設計すれば、バグの温床にはならないと思いますよ

回答No.1

dee_honda

ここでいう論理削除とは、
たとえば、社員マスタ（主キー：社員コード）で、
退職者に「退職者フラグ」を立たせたり
ということでしょうか？
そういうニーズはありえますね。

他には、
古いデータが溜りすぎてもうざい場合に、
削除データを履歴テーブルに移して、
元データを物理削除という手法もありえます。
テーブルが1つになるか2つかで検索時の効率等が
違ってくる可能性があります。

>例えばテーブルAのレコードAに対して、
>テーブルBのレコードが１つのみ対応するという場合、論理削除

たとえば、論理削除を採用している社員マスタで、
新たに入社した社員に、退職者の社員コードを使いまわしてつける
というケースですか？
それは、無茶かも。設計がおかしいでしょう。
主キーの一意性を脅かすような形では、
成立しないと思います。

結論は、
どちらがBetterかはケースによるので、
その場その場でBetterな方法を選択すればよろしいかと。
ということになるでしょうけれど、
というか、何を知りたいのかよく理解できていませんので、
真意に関する補足があると、また違うことがいえるのかもしれません。