ストアドプロシージャー（Stored Procedure）

ストアドプロシージャー（Stored Procedure）とは、データベースに対する一連の処理を、名前を付けてデータベースの中に保存しておき、呼び出すだけで実行できるようにしたものです。複数のSQL文や条件による分岐などをひとまとめにできるため、業務システムで繰り返し行う処理によく使われています。

現実世界に例えると、ストアドプロシージャは倉庫の担当者に預けておく「月末の棚卸し手順書」のようなものです。毎回細かく指示を出さなくても、「月末の棚卸しをお願いします」と一言伝えるだけで、決まった手順をまとめて片付けてもらえます。

呼び出すだけで処理がまとまって動く

基本の使い方です。ストアドプロシージャは、あらかじめデータベースに登録しておき、アプリケーションからは名前と必要な値を渡して呼び出します。「注文を確定する」「月次の集計をする」といった、複数の手順からなる処理を1回の呼び出しで実行できるため、アプリケーション側の記述もすっきりします。

通信の回数を減らせる

性能面の利点です。アプリケーションからSQL文を1つずつ送ると、そのたびにデータベースとの通信が発生します。ストアドプロシージャにまとめれば、処理はデータベースの中で完結し、通信は呼び出しと結果の受け取りだけで済みます。大量のデータを扱う処理ほど、この差が大きくなります。

権限を絞って安全にできる

セキュリティ面の利点です。利用者には、表を直接読み書きする権限を与えず、決められたストアドプロシージャを実行する権限だけを与える、という使い方ができます。こうすると、許された手順以外ではデータを変更できなくなります。また、値を渡す仕組みを正しく使えば、SQLインジェクションのような攻撃も防ぎやすくなります。

値を受け渡して使い回す

柔軟に使うための仕組みです。ストアドプロシージャには、呼び出すときに値を渡す「入力」と、処理の結果を受け取る「出力」の引数を用意できます。たとえば顧客番号を渡して、その顧客の注文の合計を受け取る、といった使い方です。渡す値を変えるだけで同じ処理を何度も使い回せるため、同じようなSQL文をあちこちに書かずに済みます。

似た仕組みとの違い

データベースには、処理を保存しておく仕組みがほかにもあります。呼び出し方や動くきっかけによって、次のように使い分けられています。

データベースごとに書き方が違う

注意したい点です。ストアドプロシージャの書き方は、データベースの製品ごとに異なります。OracleではPL/SQL、SQL ServerではTransact-SQLという独自の言語で書くのが一般的です。そのため、別のデータベースに乗り換えるときは、ストアドプロシージャを書き直す必要があり、乗り換えの手間が大きくなります。

管理の難しさ

運用での課題です。ストアドプロシージャはデータベースの中に保存されるため、アプリケーションのプログラムと比べて、変更の履歴の管理やテストがしにくい面があります。誰がいつ何を変えたのか分からなくなると、不具合の原因を追えません。定義をファイルにも残し、プログラムと同じように変更を管理する工夫が大切です。

どこまで任せるかの判断

設計の考え方です。業務のルールをデータベースの中に多く書きすぎると、処理があちこちに散らばり、全体の見通しが悪くなります。大量データの集計のように、データベースの中で行うほうが効率的な処理はストアドプロシージャに任せ、それ以外はアプリケーション側に書く、というように役割を分けるのが一般的です。

あわせて知っておきたい用語

• SQL：
  データベースに問い合わせや操作を行うための言語です。
• トリガー：
  データの変更などをきっかけに、自動で処理を実行する仕組みです。
• SQLインジェクション：
  不正な文字列を入力して、データベースを不正に操作する攻撃です。
• Oracle Database：
  企業の基幹システムで広く使われているデータベースです。