この記事の執筆理由
システムチームでのMTGの際に、論理削除としてどのようなカラムが適切かという話になった際に、不用意なdelete_flagは使用すべきでないという結論になりました。
個人的にはなるほどな！と思う点があったので今回ご紹介できればと思っています。
結論
先に結論を書いておくと、delete_flagはカラムには0か1の情報しか持てないから です
なので、論理削除したいカラムでは、「deleted_at」 を使いましょう。
delete_flagを使うデメリット
①履歴管理が難しい
delete_flagを使用すると、カラムには0か1の情報しか持てません。
そのためいつレコードが論理削除されたのかという履歴情報を保持することができません。
このレコードがいつ削除されたのかという情報は非常に重要です。
～例～
あなたは、注文サイトのECを管理しています。
あるとき上司から、顧客Aさんの注文を削除した日を調べて欲しいと言われました。
この時、delete_flagで削除を管理していた場合だと、Aさんの注文状態は分かりますが、いつ 削除されたのかという情報はカラムからは判断することはできません。
アクセスログをたどっていけば分かるかもしれませんが、非常に時間がかかるし正確な情報にたどり着けない可能性があります。
もし、delete_atで削除を管理していればDBでSQLを叩けば一発で調べることができます。
②クエリが不自然になりやすい
削除されていないレコードを抽出する際にはSQLのクエリですべてのSELECT文で delete_flag=0 を含める必要があります。これは、delete_atを使用しても同じではありますが、deleted_at IS NULL といったクエリのほうが自然に感じます。
また、Laravelを使っている場合は標準機能として、delete_atが備わっているので、わざわざdelete_flagを用いるメリットはないでしょう。
まとめ
DB設計時には、実務でどのような抽出データが必要なのか考えてカラムを作成することが大事です。
また、カラムに持たせる意味についてもきちんと考えて設計を行いましょう。
そして！基本的には「deleted_at」を用いて論理削除を行いましょう！
いつ削除されたレコードかという情報はとても大事！