「ストアドプロシージャは悪」
「もう時代遅れ」
DB設計やアプリ設計の話になると、こんな声をききます。
今回この背景を調べてみると、過去の現場にて思い当たる内容も含まれていたので記事にしてみようと思いました。
この記事では
・なぜストアドプロシージャが生まれたのか
・なぜ最近は嫌われがちなのか
・今の王道設計との関係
を整理します。
ストアドプロシージャは何のために生まれたのか
ストアドプロシージャは、DB側に処理をまとめるために生まれました。
当時の主な目的は以下です。
①通信回数削減と性能向上
アプリが、
SQLを送る→結果を受け取る→またSQLを送る
という往復を繰り返すと、ネットワークコストが高くなります。
ストアドにまとめることで1回の呼び出しで一連の処理を完結できました。
これは本当にその通りで、現場でもストアドプロシージャを使うことでアプリの処理性能を５倍、６倍に引き上げたことがあります。
長年性能改善を行ってきた経験がありますが、よっぽど品質の悪いSQLではない限り、SQLを見直すより通信回数を一度減らすように工夫したほうが、数十倍～数百倍の性能改善が見られるケースは多かったです。
②処理ロジックの再利用
同じ更新処理や集計処理を複数アプリ・複数画面で使い回す。
③トランザクションをDB内で完結
複数のINSERT/UPDATE/DELETEを確実にまとめて成功・失敗させるため、DB側で制御するのが安全。
④セキュリティ
テーブルへの直接アクセスを許可せず、「このプロシージャだけ実行可能」という権限設計ができた。
ストアドプロシージャはなぜ嫌われるようになったのか
理由は単純で、現代の開発スタイルと噛み合わなくなったからです。
以下に整理します。
①可読性と保守性が低い
ストアドは
・DBごとの独自言語
・IDE支援が弱い
・複雑になると地獄
になりやすく、属人化しがちで、「書いた人しか触れないコード」になりやすいのが最大の問題です。
これも本当にそのとおりでした。
過去に作成された長大なストアドプロシージャを改善する必要があるものの、あまりにも煩雑で修正が困難なため、手を付けられずに頭を悩ませている現場をいくつも見てきました。
ストアドプロシージャの修正を、経験豊富なエンジニアが担当するのであればまだ良いのですが、DBには詳しい一方でコーディングに不慣れなエンジニアが触ってしまうと、もはや誰も手を付けられない状態に陥ってしまうこともありました。
②バージョン管理とレビューが難しい
アプリコードは、
・Git管理
・差分確認
・CI
・Pull Requestレビュー
が当たり前ですがストアドはDBに直接定義されることが多く、運用が破綻しやすい。
③テストしづらい
ユニットテストが書きにくく、
・DB必須
・データ準備が重い
・失敗時の切り分けが困難
という問題がある。
④DB依存が強すぎる
T-SQLやPL/SQLなど、DBを変えるとほぼ書き直しになります。
※クラウド移行・マルチクラウドとの相性が悪い。
今の王道はどうなっているか
役割分担
・アプリ層：
業務ロジック・制御・検証
・DB：
データの永続化と整合性担保
サーバ間通信を前提に設計する
アプリとDBは
・別サーバ
・別AZ
・別VPC
が前提です。
そのため
・無駄な往復をしない
・まとめて取得する
・API設計で解決する
という方向に進みました。
ORMの成熟
ORMやQuery Builderの進化により
・安全
・可読性
・テスト容易性
を確保しつつ、アプリ主導でDB操作が可能になりました。
ストアドは本当に不要なのか
今でも有効なのは
・大量データの一括更新
・集計系バッチ
・通信回数を極端に減らしたい処理
です。
ただし「局所的・限定的に使う」
これが今の現実的な立ち位置です。
まとめ
ストアドプロシージャは
・時代遅れだから嫌われているのではない
・使い所を間違えると地獄になる技術
今の王道は、
アプリ主導＋DBはシンプル
通信は設計で減らし、ストアドは「最後の切り札」
「嫌われ者」になった背景を理解すると、感情論ではなく設計判断として扱えるようになります。