背景

ECサイトで商品削除機能を追加する際、物理削除と論理削除を明確にしてから実装設計に着手する。
(自分用メモ)

物理削除とは

データをDELETE(Railsだとdestroy)でデータベースから完全に削除すること。
データは完全に削除され復元や参照が出来ない。

論理削除とは

実際に削除するのではなくデータベースに削除の目印(フラグ)を設定し、削除フラグをもつデータは表示させないことでユーザーには削除しているかのような振る舞いに見せること。

メリット

・謝って削除したデータを復元できる。(後からメーカーに商品を復活してほしと以来された時も過去のデータをそのまま復元できる)
・削除したデータも参照できる

デメリット

・物理削除よりも処理が複雑（考慮すべき項目が増える）
・データ表示の際where句で絞り込みを行うのに削除フラグの条件を追加する必要がある(コードが削除フラグだらけになる)
・データが増加し続け、データベースの容量の圧迫・パフォーマンス性の低下を起こす可能性がある

物理削除と論理削除どちらが良いのか

基本的にデータの削除自体が推奨されていない。
例えば１度オーダーのあった商品を削除してしまうと、オーダー一覧には存在するのにその商品データは存在しないという状態はバグを引き起こす一因になってしまう。
一方で、販売中止になった商品がいつまでも商品一覧に残っているのは運営管理者には作業の非効率化に繋がる。
また論理削除デメリットにも上げた通りデータ量の増大に伴う検索等のパフォーマンスの低下にも繋がる。

大切なのは業務要件を踏まえて残すべきデータ・物理削除するデータ・論理削除するデータを精査すること。
また論理削除したデータについても一定の期間を過ぎたものは物理削除するなどのメンテナンスも必要。

商品(product)削除の設計[自分用メモ]

自分メモ用なのでデータ構造については省略

①関連テーブルを洗い出す
・productのPK(プライマリーキー)を持つテーブル（product_idを参照しているテーブル）の洗い出し
・productが参照しているFK(フォーリンキー)のテーブル洗い出し
・上記２つを元にER図を作成

②商品と紐づけて削除するテーブルと残しておくテーブルを分ける
例)
メーカー・・・残しておくテーブル
カテゴリー中間テーブル・・・削除するテーブル
削除する場合→depedent::destroy

③削除するテーブルの中で論理削除か物理削除か分ける
例)
カテゴリーの中間テーブル・・・物理削除
オーダーの中間テーブル・・・論理削除
※論理削除はgem:paranoiaを使用