DFU, Query, SQL

47. (3) ストアド・プロシージャとSQLの関係

データ・ベース・サーバーにアクセスする方法として ODBCや JDBCという
手法が用意されている。
これはデータ・ベースが保管されているサーバーに対して外側のクライアントから
SQLSELECT文などを要求して結果を取得するというものである。
ORACLEMySQLなどもこのようにしてSQLによってデータ・ベースへの
アクセスを可能にしている。
IBM iのユーザーは DB2/400というデータ・ベースを利用していて
RPGCOBOL,CLPなどで READ命令や RCVFコマンドでレコード単位で
 データ・ベースの中から求めるレコードだけを抽出できるのが
当たり前のように感じていると思うが他のデータ・ベースでは
レコード・レベルの抽出などはあり得ない。
一般に世間でいうデータ・ベースとは SQLとセットになっていて
SELECT文などで求めるレコードを抽出する。
例えば商品コードが NV-CF1 であるレコードを抽出するには


     SELECT * FROM QTRFIL/SHOHIN WHERE SHCODE = 'NV-CF1'

というSELECT文をデータ・ベースに投げかける。
データ・ベース・システムはすべてのレコードを読み取って
その中から SHCODE = ‘NV-CF1’ の条件に合うレコードだけを
抽出するのである。
対象データ・ベースが 30万件レコードであれば
30万件のレコードをすべて読み取ってから初めて目的の
レコードを抽出できるのであるから途方もなく時間がかかるのは
想像のとおりである。
一般企業なら数十万件から数百万件レコードを保有しているのも
珍しくはない。
IBM iのように数百万レコードがあっても瞬時に目的のレコードだけを
取り出すことができるコンピュータは他にはないのだ。
このことがあまり認識されずに他のオープン系のシステムに
移行するととんでもないパフォーマンス低下で大問題になってしまうことは
まちがいない。

さて前置きが長くなったがODBCJDBCのパフォーマンスを改善するには
どうすればよいだろう。
そのために開発されたのがストアド・プロシージャー(STORED PROCEDURE)と
いう技術である。
SELECTによって得られるアクセス・パスを保管しておいて再利用しようと
いう考え方である。

SQL文をストアド・プロシージャーとして登録しておく仕組みにするなら
SQL文も実行をかなり速くすることができる。

ストアド・プロシージャーの詳細はこのサイトの「作って理解するストアド・プロシージャー
 として何回かに分けてくわしく解説されているのでそれを参照して欲しい。