READ/CHAIN 等 IBM i 固有機能と SQL の違いまとめ
当記事は、「IBM i RiSING」2025年Aチームの成果物となる記事の一つです。
まとめはこちら
どうしてこうなった？
- 弊社と新しい形式を扱う他社で大きな違いがあったから
- 詳細を省いて結論だけを述べるとSQLを使ったほうが良い
- 新しくプログラムを作成するのなら旧来の方法を使う利点はない
- 慣れるためにも新しいものに早く入り浸ったほうが良い
- ザックリまとめると次の通り……
| 観点 | READ/CHAIN 等 (従来型) | SQL (集合指向) |
|---|---|---|
| 新旧 | かなり古い | 古い |
| 模範 | 手続き型 | 宣言型 |
| アクセス方式 | レコード指向 (1 件ずつ) | 集合指向 (複数件まとめて) |
| 主な命令 | READ, READE, READP, CHAIN, SETLL, SETGT, WRITE, UPDATE, DELETE | SELECT, INSERT, UPDATE, DELETE, DECLARE CURSOR, FETCH |
| コード量 | 多くなりがち | 簡潔に書ける |
| パフォーマンス | 単純処理では軽快 | 最適化エンジンで効率的 |
| 柔軟性 | ファイル定義に依存 | 複雑な条件・結合が可能 |
| 学習コスト | RPG/COBOL経験者には馴染みやすい | SQL標準知識が活かせる |
両者の詳細
-
READ/CHAIN 等
- SQLができる前から存在
- 手続き型
- 1ライン毎に検索するため極単純な場合は高速
- 小規模処理や単純な検索ではオーバーヘッドが少ない
- だが記録媒体が磁気テープの時代はともかく現在の筐体では誤差
- 1件ずつ処理するため大規模処理には不向き
- 小規模処理や単純な検索ではオーバーヘッドが少ない
- ジャーナルが不要
- 当然巻き戻しはできなくなる
- ジャーナルを無くせばその分データ量を軽くできる
- ただし現在でそこまでデータ量が切羽詰めることはないと思いたい
- RPG/COBOL プログラマにとって直感的で分かりやすい
- 現在ではこれらしか扱えないプログラマの方が珍しいだろう
- ファイル構造の影響を強く受けるため柔軟な操作が難しい
- 論理ファイルに定義されていないレコード順ソートなどが不可
- 複雑な定義なども苦手とする
-
SQL
- 方言こそあるが様々な環境で使うことが可能
- プログラマーの育成や募集が行いやすい
- 可読性が高く引き継ぎや保守も容易
- 宣言型
- 柔軟な処理が可能
- 複数のデータベースを合わせてなども用意
- 複雑な命令も機械が勝手に最適化して動かす
- 方言こそあるが様々な環境で使うことが可能
実際に RPGIV と類似したコードを RPGIII で作成した際に思ったこと
RPGIV は SQLRPGLE で記述されていたが弊社では OS のバージョンが古いままで RPGIII メインかつ SQL 自体が特殊な方法でしか使えないという前提だと……
- あいまい検索の難易度が違いすぎる
- SQL 不使用では別途 CL でコードを作成する必要あり
- SQL はメタ文字で容易に実装可能
- 論理ファイルで定義されたキー以外での検索は SQL でないと厳しい
以下 RPGIII と IV に起因する違い
- 変数やレコード名、プログラム名に使える名前の文字数制限が違う
- 当然厳しいのは RPGIII、変数名をかなり略す必要があり可読性は低い
- RPGIV と変数名やレコード名を揃えたかったが無理だった
- GOTO が難しくて怖い
- 他言語では半ば禁じて伴っている GOTO は RPGIII では今も必須
当記事の著作権はIBMに帰属します。詳細はこちらを参照ください。