ストアドプロシージャ

ストアドプロシージャとは

通常、業務のロジックはアプリ側（プログラム）に書き、必要なときに SQL を投げて DB とやり取りします。ストアドプロシージャ は、その 一連の処理を DB の中にあらかじめ保存 しておき、アプリからは名前を指定して呼び出すだけで実行できるようにする仕組みです。

中身は単なる SQL の並びだけでなく、変数・条件分岐・ループといった 制御構造 も書けます。いわば「DB の中で動く小さなプログラム」です。

-- 在庫を減らし、足りなければエラーにする手続きの例
CREATE PROCEDURE reduce_stock(p_item_id int, p_qty int)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE items SET stock = stock - p_qty
  WHERE id = p_item_id AND stock >= p_qty;

  IF NOT FOUND THEN
    RAISE EXCEPTION '在庫が不足しています';
  END IF;
END;
$$;

呼び出す側は、複雑な手順を意識せず CALL reduce_stock(42, 3); のように一声かけるだけで済みます。

利点：性能とロジックの一元化

ストアドプロシージャの代表的なメリットは 2 つあります。

• 通信回数の削減（性能）: アプリと DB の間の往復は意外と高くつきます。「在庫確認 → 更新 → 履歴記録」のように何度も SQL を投げる処理を 1 つの手続きにまとめれば、呼び出しは 1 往復で済みます。中間結果を大量にアプリへ送り返さずに DB 内で完結できるのも効きます。
• ロジックの一元化: 「この業務ルールは必ずこの手順で」という処理を DB 側に集約できます。複数のアプリ（Web、バッチ、別言語のサービス）が同じ DB を使う場合でも、全員が同じ手続きを呼べばルールがブレません。

観点	アプリ側に書く	ストアドプロシージャ
DB との往復	手順ぶん何度も発生	1 回の呼び出しに集約
ロジックの置き場所	各アプリに分散しがち	DB に集約・共有しやすい
権限管理	テーブルに直接権限	手続き経由に限定できる

欠点：移植性とメンテナンス性

便利な一方で、無視できない弱点もあります。

• 移植性が低い: 手続きを書く言語は DB 製品ごとに大きく異なります（PostgreSQL の PL/pgSQL、Oracle の PL/SQL、SQL Server の T-SQL など）。別の DB へ乗り換えるとき、テーブル定義以上に書き直しの負担が大きくなりがちです。
• テスト・差分管理がしづらい: ロジックが DB の中にあると、アプリのコードのように単体テストや差分レビュー、バージョン管理に乗せにくくなります。意識して仕組みを整えないと、誰がいつ何を変えたか追いにくくなります。
• 可読性・分業のしづらさ: 業務ロジックがアプリと DB に 二分 されると、全体像を掴むのに両方を読む必要が出ます。デバッグもアプリのデバッガが効かず、難しくなりがちです。

観点	注意点
移植性	DB ごとの方言で書き換えコストが大きい
バージョン管理	コードのように差分・レビューに乗せにくい
テスト	単体テストの仕組みづくりに工夫が要る
見通し	ロジックがアプリと DB に分かれて追いにくい

使いどころの整理

利点と欠点を踏まえると、ストアドプロシージャは「向く処理」と「向かない処理」がはっきり分かれます。

向いている	向いていない
何度も往復する重いバッチ処理	1 回の単純な取得・更新
全アプリ共通で守らせたい業務ルール	アプリ固有で頻繁に変わるロジック
大量の中間結果を DB 内で完結させたい集計	画面表示など可読性・保守性を重視する処理

ストアドプロシージャは、性能とルールの一元化という明確な強みを持つ反面、移植性や保守性を犠牲にしがちな諸刃の剣です。利点と欠点を天秤にかけ、「ここは DB 側が適任」と言える範囲を見極めて使うのが、うまく付き合うコツです。