渋谷の片隅で吠える

エンジニアをしています。主にscalaとjavaを書いています。

DBにおける論理削除について考えてみた

そもそも論理削除とはなんなのか

DBの基本操作は4つ CRUDと略される「create(新規作成)」「read(読み取り)」「update(更新)」「delete(削除)」

このうち実際に使っていくと問題になるものがある。 それがdelete。

とあるテーブルの一定の条件を持つデータが不必要になったのでdeleteしようとする。 しかしこのデータが他の箇所で参照されている場合このデータを安易に削除することはできない。

こんな時に使うのが論理削除である。 具体的には新たにカラムを追加しそのカラムの型をbooleanにする。 そしてクエリ側で追加したカラムがtrueの時には(またはfalseの時には)取得をしないという処理で該当箇所へのデータをクエリから流さないように制御することができる。

これが論理削除の基本である。

しばしば問題になる論理削除

これは非常に便利で強力な考えだ。 何かプロジェクトをたちあげた時にDB設計をすると必ず入れたがる人がいる。

しかし本来あるべき状態の時には不活性で活性するのは非表示にするのみのレコードをデータとして持たせるのはいかがなものかという議論がある。

ないくていい仕組みができるなら 削除できた方がトランザクションもDB容量も圧迫されずに済むからだ。

delフラグは思考停止といいうひともいるくらい。 DELETE_FLAG を付ける前に確認したいこと。

具体的な対処をかんがえないといけない。

とりあえずの回答

プロジェクトの歴史によってdelがつけられる背景は様々である。 中には思いもよらぬピボットのために泣く泣くdelを作ったのかもしれない。 この議論には一定のプラクティスはあるかもしれないけど、基本は設計の段階での想定をいかにするか。運用する人や営業の人と密にコミュニケーションをとってありそうな状況を想定するしかないのだと考える。