ストアドプロシージャとそれに関連するデータベースの管理命令を取り上げてきました。ストアドプロシージャは、既に述べてきたようにデータベースに保存されるオブジェクトで、その処理にはデータベース・サーバーの資源が使われます。データベースを操作する様々な命令は、当然クライアントのアプリケーションからも実行できます。ここで、データベースを操作する命令をストアドプロシージャとしてサーバー側で実行するべきなのか、クライアント側のアプリケーションで実行するべきなのか、考えておきましょう。
- マスター保守はストアドプロシージャで -
まず、「商品_mr」や「仕入先_mr」などのいわゆるマスターテーブルに対して、レコードの追加・削除・更新を行う保守処理では、レコードの特定や確認のための画面表示など具体的な仕組み――フロントエンド部分――は、当然のことながらアプリケーション側で構築します。
が、その処理の中から呼び出される最終的なSQLの部分は、ストアドプロシージャとしてデータベースの設計者側で予め準備しておいた方がよいでしょう。マスターテーブルの保守はデータベースやシステムの管理者だけが行う限定的な処理なので、複数のアプリケーションから実行されることは通常ありません（もし、複数のアプリケーションでマスターの保守を行うような仕様のシステムがあったとしたら、それは設計ミスだと思います）。
しかし、マスターテーブルはデータベースとそれを利用するシステム全体にとって基本的なオブジェクトです。そのため、マスターテーブルに対して変更を加える処理は、データベースの設計と絡めて統一的に設計・実装する方が安全かつ効率的です。
- アプリからはブラックボックス -
マスターテーブルに対してレコードの追加や削除を行うストアドプロシージャでは、パラメータを採るように設計しておくと汎用性が高まります。ここで言う「汎用性」とは仕様の異なる複数のアプリケーションから利用できるという意味ではなく、単一の管理用アプリケーションに対してその設計上の自由度を広げられる≪寛容性≫という意味合いです。
但し、パラメータでテーブルを指定できるようにした場合、アプリケーションのソースレベルで指定したテーブル名が間違っていてエラーが発生すると、アプリケーション側のデバッグでその間違いを見付けることが困難になります。アプリケーションのソースでは、実行するストアドプロシージャ名もそのパラメータも単なる文字列として扱われるためです。
ストアドプロシージャは、アプリケーションから呼び出される段階ではブラックボックスとなっており、その中身を確認できません。アプリケーション以前にストアドプロシージャの設計をしっかり行い、バグを取り除いておく必要があります。
- 特定の環境に依存しすぎないこと -
長くて複雑で、しかもその内部から他のストアドプロシージャやユーザー定義関数を呼び出すような構造のストアドプロシージャを作る人もいますが、あまり複雑すぎるとバグを見つけるのに手間がかかります。
ストアドプロシージャを記述する言語は、一般的なプログラミング言語とは違ってデータベース・エンジンごとに命令や文法の異なる部分も多いため、あまり複雑な処理を作ると汎用性もなくなってしまいます。
データベースをあれこれとっかえひっかえするようなシステムはあり得ないため、特定のRDBMSだけを相手にしているならそれでも構わないでしょう。が、受注システムを開発する場合、RDBMSもプログラミング言語も特定の製品だけではツブシの利かなくなることもあります。
こういった点を考慮して、汎用的でシステムの仕様に合わせて書き換えやすいストアドプロシージャを作れるようにした方が有利だと思います。
ストアドプロシージャに続けてデータ定義命令を紹介してきました。GUIでもできるテーブルやビューの作成・変更は、わざわざコードを記述して操作する必要などなさそうな気もします。
が、大規模なデータベースを複数相手にするような場合、少しでも効率的で間違えにくい設計・運用・管理を行うためには、ストアドプロシージャ化したデータ定義処理が役に立ちます。頻繁に作成するものではありませんが、汎用的な処理をいくつか用意しておけば作業の効率化が実現できるでしょう。
 サンプルファイル (ZIP形式 4KB)
 |
|
|
