前回、埋め込み SQL へ書き換える元の RPG/400、ILE RPG を紹介しましたが、今回は SQL を使って書き換えたその全文の紹介です。
まず、ソースのわかりやすさや SQL のスキルが使える、というのがポイントですね。
埋め込み SQL がけっこうかんたんに使える、ということ、
サイズやパフォーマンスについてもほとんど心配は要らない、ということもあわせて紹介したいと思います。
こちらが SQL を使用して書き換えた例です。
H DATEDIT(*YMD)
*
FQPRINT O F 132 PRINTER OFLIND(*INOF)
*
D KINARR S 11 0 DIM(4)
D KIN S 11 0
*
D HI S 1 0
*
/free
//カーソル定義
exec sql DECLARE C1 CURSOR FOR
SELECT CASE WHEN DEC(SUBSTR(jhdate,5,2)) < 11 THEN 1
WHEN DEC(SUBSTR(jhdate,5,2)) < 21 THEN 2
WHEN DEC(SUBSTR(jhdate,5,2)) <= 31 THEN 3
ELSE NULL END AS HI,
SUM(jhking)
FROM Jumidp
GROUP BY CASE WHEN DEC(SUBSTR(jhdate,5,2)) < 11 THEN 1
WHEN DEC(SUBSTR(jhdate,5,2)) < 21 THEN 2
WHEN DEC(SUBSTR(jhdate,5,2)) <= 31 THEN 3
ELSE NULL END ;
//カーソルのオープン
exec sql OPEN C1 ;
//見出し印刷
except MIDASI ;
//受注見出しファイルの読み込み
DoU (%subst(SQLSTATE:1:2) <> '00') ;
exec sql FETCH C1 INTO
:HI,
:KIN ;
if %subst(SQLSTATE:1:2) = '02' ;
leave ;
else ;
KINARR(HI) = KIN ;
EndIf ;
EndDo ;
//合計処理
KINARR(4) = %xfoot(KINARR) ;
except SAISHU ;
//終了処理
exec sql CLOSE C1 ;
*inLR = *on ;
return ;
/end-free
*
OQPRINT E MIDASI 02
O 6 'RPG040'
O 43 ' **** 受注集計表 **** '
O 77 '作成日'
O UDATE Y 86
O 95 'ページ'
O PAGE Z 100
O E MIDASI 04 06
O 28 '** 1 - 10 **'
O 47 '** 11 - 20 **'
O 66 '** 21 - 31 **'
O 85 '** 1 - 31 **'
O E SAISHU 0
O KINARR(1) J 29
O KINARR(2) J 48
O KINARR(3) J 67
O KINARR(4) J 86
サブルーチンはまったく必要なくなっています。
全体としてコンパクトになったので、こちらの方がさらにロジックは追いやすいのではないかと思います。
さて、それぞれの比較ですが、まずサイズを見てみましょう。
| RPG/400 | ILE RPG | ILE SQL RPG |
| 90KB | 140KB | 228KB |
確かに少しずつ大きくなっていますが、数百KB の差ですね。
パフォーマンスですが、それぞれ適当に二回ずつ実行してみて、PEX のプロファイルから Total DB CPU (μs) を取ったものを見てみました。
| RPG/400 | ILE RPG | ILE SQL RPG |
| 89,640 | 29,928 | 28,312 |
| 59,976 | 25,608 | 16,104 |
SQL RPG は特に ILE RPG にくらべて遅いということはないことがわかりますね。
（RPG/400 はやはり比較すると有意に遅いと言ってよさそうですが）
今回の処理は月内の日付で分類するロジックになっており、その日付フィールドが 6桁の数字フィールドになっていたため（"時代の制約" ですね）に SQL では「数字 → 文字 → 改めて数字（分類のため）」と二回もコード変換をするはめになっています。つまり、お世辞にも効率がよい SQL とは言えないんです。
それでも RPG/400 よりは速く、ILE RPG と同等かむしろやや速いという結果を出しているわけです。
（元のテーブルが日付タイプだったら日付関数が使えてもっと効率がよかったと思うのですが、、テーブルのデータタイプを ALTER TABLE で変更するのもチューニングのひとつになるでしょうね）
もし「遅い」とか「難しい」とかいった先入観があって埋め込み SQL を利用していないのであればとてももったいないことだと思います。
事実はそんなことはないんですね。
通常の RPG を埋め込み SQL に書き換えるだけで CPU 時間が減ってしまう（= レスポンスタイムが速くなる/ CPU % が下がる）ことがある、ということを今回紹介してきた一連の例で見ることができたわけです。
もちろん、必ずそうなるかどうかはケースバイケースなので何とも言えませんし、そうならないケースも出てくるでしょう。
それでも、もしそういったパフォーマンスのメリットがなかったとしても、データベースアクセスの標準が世の中で SQL なのは間違いのないところです。
埋め込み SQL のスキルは今後も重要なものであり続けるでしょうし、対話型 SQL でデータ選択/取得部分のテストが出来てしまうなどの開発ののしやすさ、などを考えるとやってみる価値は確実にあると思います。
実際、"オブジェクト指向" なんてのはパフォーマンスのメリットはほぼないにもかかわらず現在の主流になりつつありますよね!?
より詳しい情報はインフォメーション・センターにあります。
基本は F 仕様書をカーソルに変えること、レコードの読み込みは FETCH、まとめてできるようなことには SQL の機能を活用すること、の三点です。
ぜひ挑戦してみてください!! そんなに難しいことではありませんから。