論理削除はアンチパターンらしい
fukabori.fmで論理削除の話をされていたので、書いてみます。
個人的にはほとんど論理削除で作ります。
アンチパターン
最初に論理削除の説明やアンチパターンの理由について話されています。
納得できる部分が多く、実際にデータ量やSQL文の冗長だったり忘れて期待通りの値が取得できないことがありました。
たしかに使用しているＯＲＭにも実装されていないし、プラグインやwhereで対処しています。
なるほど。と実感しましたが、個人的には論理削除で作成していくと思います。
ユーザーの誤操作
理由は対応していたビジネスがＢtoＢtoCでサービスを利用している会社の人の誤操作や詳しくないユーザーの操作などで問い合わせがある際に対応をするために論理削除にしています。
このあたりはpodcastでも話されている通り、解決策がないと思っています。
削除用のテーブルに一時退避とか、バックアップ用のテーブルから引き出すことも考えましたが、削除用のテーブルの管理コストやバックアップの復元時間がネックになってくると思います。
パフォーマンスに影響があるテーブルについては対応しますが、マシンパワーに頼ってアプリケーションを作っていると思います。
クラウドのお陰でマシンパワーで解決できることは気にしないところが多くなった気がします。開発スピードを意識していた部分もありますが、これからはテーブル設計についても検討したほうがいいと認識できました。
ＵＩをわかりやすく作るのも重要ですが、試行錯誤の結果よくなっていくと思っているため難しい内容だと個人的に思っています。
世の中のＤＢ設計ってどれくらいの規模が論理削除採用してないんだろう。
いままで関わってきたプロジェクトはほとんど論理削除だからアンチパターンとか考えたことなかったです。
考える機会になってよかったです。
fukabori.fmいいですね。
