SQLによる処理を、何でもかんでもストアドプロシージャにすればよいというものではありません。サーバー側に保存されるプログラムであることを考慮し、必要な処理だけをストアドプロシージャにしましょう。
- サーバーの負担に注意 -
ここまでは、まだ非常にシンプルな処理しか紹介していませんが、ストアドプロシージャではSQLで実現できるすべての処理を定義できます。ただ、その保存場所が『データベース』であることに注意してください。ネットワーク上の複数のクライアントが一斉に１つのストアドプロシージャを実行した場合、データベースサーバーに過度の負担がかかる上にネットワークのトラフィックも増加します。
ストアドプロシージャの実行は、対象となるデータベースを実行しているサーバー側の負担となります。そしてその処理結果は、ネットワークを通じてストアドプロシージャを呼び出したクライアントへ送られます。
サーバーとネットワークに負担をかけないよう、ストアドプロシージャは〈必要最低限〉の処理とするべきです。クライアント側のアプリケーションでSQLを発行して片付く程度の処理なら、わざわざストアドプロシージャにする必要はありません。多くのアプリケーションで共用されるような処理や、サーバー側で実行した方が効率的な処理だけを、ストアドプロシージャとするのが正当です。
- 汎用的な処理を -
では、具体的にどのような処理がストアドプロシージャ向きでしょう？ 条件の第一は『汎用的な処理』であることです。プログラミング経験のある人なら、この意味はすぐにお分かりいただけるでしょう。
例えば、画面に文字列を表示する処理（C言語のprintf関数など）は、どのようなアプリケーションでも利用する可能性があります※3。だから、標準関数として処理系に備わっているのです。もしこの関数が予め用意されていなければ、世界中のあちこちに同じ目的（文字列表示）のための異なる関数が散在しているでしょう。
データベースでも、こういった『様々なアプリケーションで利用される処理』は存在します。それらはストアドプロシージャにふさわしい処理です。但し、あまり凝った仕組みを作り上げる必要はありません。いろいろな目的を持ったアプリケーションから共通して利用できるよう、ストアドプロシージャはできる限りシンプルであるのが理想です。
※3 GUIと統合開発環境が当たり前となった昨今では、画面にメッセージを出すためにprintf関数を使うなんて、学校のお勉強くらいでしか経験していない人も多いと思います。が、グラフィックスを使わないいわゆるCUI環境でのメッセージ表示は、プログラミング技術の基本です
- ストアドプロシージャ向きの処理(１) -
具体的には、以下のような処理がストアドプロシージャ向きです。
1.テーブル内容の一覧
2.IDをキーにした単純な問い合わせ
3.現時点での在庫数や取引額などを調べる単純な集計
4.月次・年次のテーブルの転記処理（コピーと削除）
5.新規テーブルの作成や既存テーブルの削除
1.2.3.のようなアプリケーションで多用される処理は、共用処理としてストアドプロシージャにしておく価値があります。もちろん、汎用性を持たせるためにうまく設計しておく必要があります。
4.5.のようなデータベース全体の保守に関わるような処理は、特にストアドプロシージャ向きです。こういった処理は間違いを許されないため、基本的にデータベースの管理者が実行する必要があります。
クライアント側で個々に作成したアプリケーションが、それぞれ独自に保守関係の処理を実行した場合、アプリケーションのバグによってデータベースの整合性を保てなくなることもあるでしょう。そのような事態を回避するために、ストアドプロシージャで保守処理の骨格部分を作っておき、クライアントからはそれを呼び出して具体的な処理を作るようにします。
- ストアドプロシージャ向きの処理(２) -
「4.月次・年次のテーブルの転記処理（コピーと削除）」の処理は、非常にストアドプロシージャ向きだと言えます。
例えば、１ヶ月の締め括りに当月の取引内容を『xxxx年xx月分集計』といった名前のテーブルに記録し、現在の取引を記録したテーブルの内容を翌月に備えてすべて削除する──といった処理を、クライアントレベルに委ねるのは危険です。そういった場合に、確実に動作するストアドプロシージャを用意しておき、クライアントのアプリケーションからはそれを呼び出すだけにしておけば安心です。
例えば、以下のような形です。
(1)受注結果を記録するテーブル「累計売上_fx」の６月分の内容を「累計売上_2005_06」という名前で保存（コピー）する
(2)テーブル「累計売上_fx」の内容をすべて削除する
もちろん、年次処理として１年分をまとめて別名のテーブルに転記しても構いません。こういった処理は複数のクライアントから実行されるものではないため、共通性という面ではメリットがありませんが、処理を間違えると大きな問題を引き起こします。そのため、実際の処理をサーバー側で管理しておく方が安全なのです。この具体例は、追って紹介します。
- 商品一覧処理の例 -
では、もう少しSQLらしい処理を作ってみましょう。
テーブル「商品_mr」の一覧を仕入先ごとにまとめて表示する処理です。
Create Procedure GetItemList
As
SELECT * FROM 商品_mr ORDER BY 仕入先ID
先ほどと同じように“EXECUTE GetItemList”と入力して上記のSQLを実行すると、ストアドプロシージャ“GetItemList”が登録されます。以下のように実行すると、テーブル「商品_mr」の内容がグリッドに表示されます。
 |
|
|
