「削除フラグ」が将来の不具合を予約する理由──『失敗から学ぶRDBの正しい歩き方』のアンチパターン20選

アプリケーションのコードは書き直せる。フレームワークを変えることもできる。しかしデータベースに一度入ったデータは、システムの中で最も長く残り続ける。設計の誤りがその後の開発コスト全体に積み重なっていく。

曽根壮大著『失敗から学ぶRDBの正しい歩き方』（技術評論社、2019年）は、現場でよく見かける RDB 設計・運用のアンチパターン 20 種を、なぜ問題なのか・どう解決するかという構造で整理する。

1. 「削除フラグ」はクエリを際限なく複雑にする

退会したユーザーや削除した注文を残すために「削除フラグ」カラムを追加するのは、一見シンプルな解決策に見える。しかし本書はこの設計を、将来に向けた問題の予約として位置づける。

すべての SELECT クエリに WHERE deleted_flag = 0 が付くことで、インデックスの選択度（カーディナリティ）が極端に下がる。削除されたレコードが増えるにつれてパフォーマンスが劣化する。UNIQUE 制約による重複防止も、削除フラグを考慮しなければ正しく機能しない。

本書が提案するのは「事実のみを保存する」設計だ。現在有効なデータと削除済みデータをテーブルレベルで分離する、あるいは VIEW を使って有効データのみをアプリケーション側に見せる。状態をテーブル構造で持たせない設計が、長期的なクエリの複雑化を防ぐ。

2. 上書き UPDATE が「ビジネスの歴史」を消す

消費税率の変更や商品価格の改定を、マスタテーブルの UPDATE で対応するのは一般的だ。しかし過去の時点で「いくらで取引されたか」という事実は、上書きの瞬間に失われる。返品処理や監査対応が必要になったときに、過去の状態を復元する手段がなくなる。

本書はこのパターンに対して、変更を UPDATE で上書きするのではなく、新しい事実を INSERT として追記する履歴設計を論じる。ただし追記し続けることはデータ量の増加を伴い、インデックス検索の劣化につながるトレードオフも存在する。データの用途によって、専用の履歴テーブルを設ける、分析基盤にログを転送するなど複数の選択肢が示される。

3. インデックスは「追加するより削除の方が難しい」

クエリが遅いたびに複合インデックスを追加する「インデックスショットガン」は、ディスク容量の圧迫とデータ更新処理の遅延を引き起こす。

本書は SQL の実行エンジンが FROM → WHERE → ORDER BY という順序でデータを処理する流れを説明した上で、インデックスが効果を発揮する条件を整理する。対象テーブルの 10% 未満のデータを絞り込む SELECT でなければ、インデックスが使われないケースがあるという基準も示す。

インデックスの管理については「MENTOR の原則」（Measure・Explain・Nominate・Test・Optimize・Rebuild）を使った継続的な運用サイクルが提案される。一度追加したインデックスは削除の判断が難しいため、追加前に測定と実行計画の確認を行う習慣が重要だという立場だ。

DevBookPath のマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

バックエンドの地図を見る ／ データベースの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。