PL/SQL導入のメリット

オラクルDBを利用するシステム開発を行う場合、PL/SQLの導入を検討されることと思います。PL/SQLを利用したクライアント・サーバアプリケーションでは、効率的な運用を実現できるとともにシステム設計、製造段階においても開発サイドで大きなメリットがあります。開発における作業分散と、複雑になりやすいクライアントソースの軽量化です。そして複雑なソースの減少により修正、保守対応が低コストで行なえます。

ここで、PL/SQLの導入メリットについて少し整理したいと思います。

お客様のメリット

ストレスを感じない使いやすいシステム運用ができます。

処理を全てクライアント側で行うシステムは、全体的に処理が重く感じる傾向にあると思います。

お客様のシステム運用環境では、他の電子媒体の資料を複数開き業務を行っていたり、他のシステムやツールを平行して使って仕事をしていたりと様々です。ひとつのシステムでメモリの圧迫が顕著に現れることで使いづらいシステムと感じるという声もありました。お客様の環境でシステムが軽いということは、使いやすいシステムであることのひとつ理由になるようです。

また、通信によるタイムラグの影響は大きく、1回のタイムラグは小さくても、それが何千回、何万回と積み重なることで体感的に感じる反応の悪さが生じます。
お客様は、このタイムラグは、仕事のリズムを乱されるとのご指摘を頂いたことがありました。

プロジェクト運営でのメリット

開発リスクの分散ができます。

プロジェクトを管理する立場からすると、リスク分散や作業負荷から生じるスケジュールの管理が難しく思われます。徐々に、変わっていく仕様にあわせ、担当者にかかる負荷が予想していたより大きくなっていくこともあるようです。PL/SQLの導入することで、クライアント側、サーバー側と分割した作業と切り分けを行なうことができるため、増員等による作業の分担がスムーズに行えるメリットがあると考えられます。

製造担当者のメリット

分割されたソースによりメンテナンスがしやすくなります。

データの登録、更新、検索でSQLを発行する場合、通信に一番時間がかかるため、SQLの発行回数を抑えようとします。このため、1SQLにテーブルの結合から、条件の場合分けを全て含めてしまいます。そうやってできたSQLを実際に解析、メンテナンス、修正、確認することに多くのコストが発生します。

PL/SQLでストアドプログラムを作成すると、SQL発行の通信の時間を考慮する必要がなくなるので、単純なSQLの組合せで処理を記述することができます。

クライアントでは画面の入力制御、画面上の値をインターフェイスへの設定、PL/SQLでは、データの登録更新やそのためのチェックを行なうなど分割することで製造後のメンテナンス、バグの発見、修正が大幅に軽減できると思われます。

但し、クライアント側とサーバー側でファイル、開発言語が分割されてしまいます。

そして、PL/SQLの導入についてはメリットより、作業工数、言語の習得、人員などに目が行きがちです。また、PL/SQLについての書籍等を見ても、SQLの説明、オラクルエラーの解決法が主な内容となっており、システム開発としての製造レベル(どの程度までPL/SQLを理解し使用すればいいか)を具体的に示したものが多くないと思います。

PL/SQLの製造について

実際、PL/SQLの製造では、どれくらいの知識、製造レベルが必要かを具体的に見ていくと、本に載っているいろいろな機能を使う必要はないように思います。というのも、あまり自動で行われるような便利機能をつかうとシステムを運用してから発生する問題で途中経過が分からなくなってしまうからです。

実際の製造で注意するべきは、

  1. 透明性があるソースであること

    わかりやすいソースとして、自動で行われてしまう処理できる限り行わなようにしましょう。データ更新は、トリガーを使わず、SQLでUPDATE文を記述しデータの更新を行います。また、パフォーマンスがあがる訳ではないのでビューは使用しません。一時データを確保する必要があるときは、ワークテーブルを作成し、その都度登録削除を行うようにします。

  2. 複雑なSQLを記述しないこと

    クライアントからSQLを実行する場合、通信に一番時間がかかるため、1回のSQLの発行で必要となるデータ全てを取得します。複数のテーブルの結合、UNION、副問い合わせを多様することになります。しかし、ストアドプロシージャを使用することにより、「1回のSQLの発行で」を考慮する必要がなくなるため、複雑なSQLを組まなくてもよくなります。

    また、暗黙カーソルを使わず、明示カーソルで記述すると、障害の発生したSQLを特定しやすくなります。

  3. LOOP文の中にLOOP文を組まない

    データは多次元で処理することが多くなります、多重にLOOPを組むときは、LOOP文のなかで関数を呼ぶようにします。1関数に多重のLOOPを記述しないようにします。

    システム運用中や、試験中にデータバグが発生したとき、その原因を突き止めるためにデータを追っていくことになります。LOOPが多重に組まれていると対象のデータ発見するため非常に多くの件数検証しなければならなくなります。そこで、LOOP内でさらにLOOPを行う場合は、関数に切り出し、切り出した関数の中でLOOPを行うようにしていると、関数ごとにデータを検証できるため、検証するデータの件数を最小限に抑えることができます。

    例:10×10の配列を同一関数で2重にLOOPを組むと100項目を検証することになります。行LOOPの中に列LOOPを行う関数を作成すると、行は行で10件、列は列で10件と20件のデータ検証を行えばよくなるのです。3重、4重でLOOPを組んでしまうと、障害の発生箇所の特定がデータの件数が多すぎるためより困難になっていきます。

  4. 障害が発生した場合、その原因を突き止めやすいソースであること

    PL/SQLは、結合試験、運用試験、運用と進めていくにしたがってブラックボックス化されます。運用が始まった場合など、本番環境での実データを使っての検証は非常に困難となります。また、試験環境へのデータ移行は、セキュリティ上できないことも多く、データの加工に手間がかかることなどからエラーはソースで落とし、可能な限り、関数戻り値、エラーメッセージを記述すると後々の対応が楽になります。例外処理については、オラクルエラー以外の指定をできる限り行うと、エラーコードで落ちた原因がわかりやすくなり、落ちた箇所の特定をしやすくなります。

    PL/SQLは単体試験がとても重要になります。

    単体試験終了後はデータをみてバグを直すことになります。試験項目標をつくるのは、とても時間がかかります。「PL/SQL単体試験項目標作成ツール」で試験項目標を出力すると自動で出力できます。コメントのチェックにもなります。実際、開発の経験上、仕様書よりも最新のソースが正確に記述されていることが重要に考えられます。

  5. 正確なコメントと、シンプルなソースであること

    引き継ぎ作業を行っても、障害が発生した場合は、直接ソースを追っていくことになります。正確なコメントとシンプルなソース、SQLで記述されていると理解が早く対応も早まります。

などのポイントが挙げられるかと思います。

補足

  1. パッケージは1度登録されるとコンパイルされません

    ストアドプロシージャ(データベースに常駐している関数)として、FUNCTIONとPACKAGEで管理する方法があります。FUNCTIONとPACKAGEの違いはFUNCTIONは呼び出すタイミングで毎回コンパイル使用されますが、PACKAGEについては、登録時にコンパイルをするだけになります。

  2. PL/SQL同士の呼び出しで引数に配列は使えません

    パッケージでの構造体の使い方には注意が必要

inserted by FC2 system