この記事はおよそ3分で読めます
はじめに
Webエンジニア2年目@_somary
普段はsalesforce関連のアプリケーション開発に従事
弊社2年目エンジニア研修”SET”で学んだ内容の中から、
DB周りで個人的に驚きのあったデリートフラグの扱いについて記す
※インフラやDB周りの知識・経験が乏しいことをご留意頂きたく。。。
初手デリートフラグ
普段DBなど全く触らないので、ネットの情報を元にDB構築のイロハを学びつつ、
"世界の多くがこうしているのだからこういうものなんだろう"という、
守破離でいうところの"守"を重んじた思考の元、設計をしていたところ、技術メンターに問われる。
「なんでそれデリートフラグいるの？」
この一言が、私のデリートフラグに彩りを与えた。
問われ、考える。何故このテーブルにデリートフラグが必要なのか。
デリートフラグいらない説
「なぜこのやり方が多数派なのか」というところまで深掘りできていなかったため、
その場では回答できず、それらしい理由を用意するための猶予をもらった。
ググる。
が、どの記事を見ても、デリートフラグについて言及していても、必要な理由についてまでは説明していない。
もはや説明するまでもないくらい常識的なものなのかと困りつつ、
ネットの情報を元にデリートフラグが必要な理由を考察してみた。
デリートフラグを実装する理由を調べてみると、世論は大きく下記の2点に分けれられると思う。
1. 復元する予定はないが、万が一には備え、かつパフォーマンス面でDELETEを呼びたくないから
2. 仕様的に削除後のデータを復元しなければならない必要があるから
いろいろな記事を見たが、個人的には1と似たような理由が多そうなイメージだった。
「パフォーマンスとして、UPDATEの方が優れているので、DELETEは使わずにフラグで管理する。」
これだけを切り取ると、非常に尤もらしい意見である。
パフォーマンス面における妥当性や、そこまで差し迫った状況があるのかはさておくとして、
そもそも、論理削除したレコードを再び参照する時はどういう状況なのか、ということをここでは考えてみたい。
復元する予定のないものを参照しなければならないのだから、容易に尋常ではないことは伺える。
そのような緊急時は、DB(oracle)の機能として提供されているロールバックを用いて、まるごとその時点まで状態を巻き戻す、
というのが推奨されている、らしい。そのためのバックアップ、そのための世代管理。
この他にも、コストをかけてよいのであれば、他にも色々やり方はある、らしい。
万が一にはDB側で対応してもらえるならば、万が一に対してわざわざ人がそれに備える必要はあるのだろうか。
エンジニアであれば、実装しなくてよいものは実装しない道を誰しもが歩みたいはずだ。
次に2についてだが、こちらはそもそも"削除フラグ"として扱うべきではない気もする。
そもそも、"削除後のデータを復元しなければならない必要"があるとすれば、
それは一時的な"状態"を表しているように思えるので、削除フラグという真偽値で管理すること自体に違和感を覚えてしまう。
まとめ
往々にして、デリートフラグでやりたいことを深掘ってみると、
それはデリートフラグでやるべきことではないケースが多い、らしい。
思考停止でデリートフラグを設定するのではなく、
そのアプリケーション、その要件に適した"削除"の扱いについて考察した上で、
リスクやコストとトレードオフして設計しなければならない、という当然の結末にたどり着いた。
今回の研修内容の場合、物理設計段階でアレコレ考えていたのだが、本来の姿としては論理設計の段階で、
要件として満たすべきものはあるのか、あるとしたらどの情報がそれに合致するのか、
ということをヒアリングしながら、最も相応しい形で設計していくのがよいのだろう。
熟考した上でのデリートフラグと、思考停止のデリートフラグでは天地の差があるのは当たり前だ。
なんとなくとりあえず保険のデリートフラグ、という単純思考を抜けられたことに、まずは成長を感じたい。
余談
調べている中で、個人的にモヤモヤしていたのだが、コンテキストによっては、
"デリートフラグ"のことを、レコードの有効無効判定として扱っているものもあれば、
本来の意味での"削除"という意味で使用しているものもあり、思考を停止し設定した人(私)がいる中で、
それらを全て同じ"デリートフラグ"として一緒くたにしてしまっていた思考に問題があった。
本質的にはそれぞれやりたいことが別なのに、同じデリートフラグという枠で論じていたら、
当然意見の不一致が出てくるはずなのだ。
fin.