データベース定義をDDLで行うべきか、DDSのままで良いかという論争は古くからありますが、適材適所で使い分けるのがベストというのが結論のようです。では、その使い分けの基準はどのようなものなのでしょうか。この記事を読み、DDLとDDSの使い分けについて、自分の会社ではどうあるべきか改めて整理し直してみてはいかがでしょう。（編集部）
DDSで定義されたファイルをDDL定義のそれに切り替え、RPGのファイルアクセスを埋め込みSQLに置き換えるべきでしょうか？簡単な答えはありませんが、両者を混ぜて使うというのが最善の選択肢かもしれません。
2008年9月1日 ジョン・パリス＆スーザン・ガントナー
「IBMは、DDSで定義されたすべてのファイルをDDL定義のそれに切り替え、RPGファイルアクセスを埋め込みSQLに置き換えるべきであると言っています。どう思いますか？」
2008年8月26日付のブログで述べたように、お客様やiカンファレンスの出席者からこの質問を度々受けます。これは、このEXTRAの記事で説明するのに良い話題のように思えますので、今月はこの題目について記事を書くことに全力を傾けます。私達は、ちょっとした調査を行い、幾つかのテストプログラムを書き、切り替えを行った何人かの人達の話を聞き、いくつかの提言を述べようと思います。それはどれ程複雑である可能性があるのでしょうか？いやはや、私達はそもそも間違っていたのです！これは、それを推進している人々の心に時として浮かぶような単純なものではないことが分かりました。
この話題を調べた結果、単純な答えなど無いと結論付けなければなりません。実際、問いは1つではなく、２つあるのです。DDS対DDLという論争およびSQL対RPGネイティブI/Oという論争です。あなたは、事実を見直して各々に対して案を立て、独力で意思決定をしなければなりません。
SQL対RPGネイティブI/O論争に関する限り、何年もの間私達の見解はほとんど変わりません。私達の見解は、最善の解決法は両者を混ぜて使用するというものです。ですから、結果セットを返すクエリの場合（たとえば、サブファイルを満たすためにデータベースを照会する場合）、私達は常にSQLを推すことになります。更新目的のために単一レコードを抽出するタスクの場合、単純なRPGのCHAIN命令が勝っています。それを超えてこのコラムでこれ以上詳しく述べる紙幅はありませんが、後程この話題に戻ってきます。
DDLのご利益
調査の中で、私達はIBMのダン・クルックシャンク氏による“Modernizing Database Access—The Madness Behind the Methods.（「データベースアクセスをモダナイズする－方法の背後にある狂気」）”というタイトルの優れた記事を見つけました。私達はダンが特別なIBM社員であることにすぐに気付きました。彼は例題にRPGを含めているのです！彼は、様々なDDS/DDL/RPG/SQLの組み合わせの間の幾つかの直接比較を、それに付随するパフォーマンス分析によって行っています。彼の主要な結論の１つは、新たに作るすべてのファイルはDDLで定義されるべきだというものであり、確かに彼のデータはこの結論を裏付けているように見えます。私達はまた、IBMのマイク・ケイン氏とジーン・コブ氏によるApplication Modernization: DB2 for i5/OS style（「アプリケーション・モダナイゼーション：DB2 for i5の流儀」）という優れたデータベース・モダナイゼーションに関するプレゼンテーション資料を見つけました。それは、データベース・モダナイゼーションという話題全体への優れた序論で、共通の問題に対するいくつかの定番の解決法を提供しています。
この情報をひとたび受け入れたら、もう１つの優れた資源は“Modernizing IBM eServer iSeries Application Data Access（「IBM eServer iSeriesアプリケーション・データアクセスをモダナイズする」）”というIBMが発行するRedbookです。私達のブログへのコメントの1つが指摘しているように、DDLは結合を含む複雑な論理ビューと同等なものをずっと簡単に作成します。ビューのビューを定義できるので、これらをもっと単純なビューの組み合わせに基づいて作成できます。これにより、作成プロセスが簡易化され、保守性の向上に役立ちます。加えて、ビューにはDDSが提供するのと同等のものを遥かに超える派生列を含めることができます。これらはまた、（RPGの組み込み関数に似た）SQL関数を活用することもできます。これらの関数はユーザー定義可能で、独自のRPGロジックを呼び出すことさえできます。
この話題に関して書かれていることの多くが、DDL定義されたファイルを使うことで、データベースに書かれるときにデータの妥当性が検査されるということを強調しています。書き込みに若干時間を要したとしても、誤りのないデータという考えは常に良いものであると私達全員が支持しています。
しかし、多くの参考資料が、妥当性検査の必要が無いお陰で、結果的にDDL定義された表からのデータ読み込みのパフォーマンスが向上することを示しています。他方、DDS定義されたファイルからのデータは書き込み時に妥当性検査を行っていないので、読み込み時に妥当性検査を行う必要があります。データがSQLで読み込まれる場合に、これが真実である（私達には確信がありませんが）一方で、ネイティブのRPGによる読み込みの場合には間違いなく真実ではありません。ファイルからデータを読み込むときに、RPGプログラムの中で十進データエラーが起きるという事実は、データベース固有の妥当性検査の結果ではありません。どちらかと言えば、それはRPGがレコードバッファから個別のフィールドを対応するストレージ上の場所に移動するという事実による機能です。このエラーのきっかけとなるのは、READまたはCHAINではなくこのデータ移動です。このことは、データ構造に直接ファイルを読み込むことで容易に証明できます。このとき十進データエラーは起こらないことに気付くでしょう。さらなる詳細については、私たちが書いた“Ending Those Decimal Data Error Blues（「十進データエラーの憂鬱を終わらせる」）”という記事をお読みください。
確かに過去に私達が書いたテストプログラムでは、順次処理においてDDL定義のファイルがDDS定義のファイルのパフォーマンスを上回ったことはありません。事実、ある結果はとても奇妙だったので、私達はそれらをここに含めていません。この結果についてはIBMと議論する予定です。マイク・ケイン氏とバーバラ・モリス氏は二人とも来るべきRPGとDB2サミットで講演するので、この結果について彼らと個人的に議論する機会があり、将来EXTRAの記事または私達のブログで報告をするつもりです。
もう1つの良否の違いは、論理ファイルが最も頻繁に8Kバイトのページサイズを使用するのに対して、DDL定義のファイルは64Kバイトのページサイズを使用することです。理論的には、これは処理速度を大きく改善する可能性があります。しかし、メモリーの制約を受けたシステムでは、より大きなページをロードするオーバーヘッドは、それが解決する問題よりも多くの問題を引き起こす可能性があります。
私達は、DDSからDDLに切り替える中で数多くの課題を発見しました。第1に小さいとは言え、学習曲線があるということです。知識を強化する良い方法は、単に腰を下ろし、DDLの構文を学ぼうとするよりも、任意のDDS（またはDDL）定義のファイルからIBM Navigator for iが生成するSQLを使い、それを学ぶことです。DBUやSurveyor/400のようなその他の人気のあるデータベース・ツールもまたこの機能を含んでいます。しかし、この単純さによって既存のすべてのファイルを変更するのは容易なことだと誤解しないでください。続きを読んでください。
DDLへの切り替えには、まったく新しい「言語」（たとえば、レコードではなく行、フィールドではなく列）が必要になることは暫し無視するとして、他のいくつかの課題が不用心な初心者を躓かせる可能性があります。一例を挙げると、DDL列（フィールド）のデフォルトはヌル値許容であり、DDSと正反対です。もう1つの障害は、多くの場合必ずしも常にRPGプログラムを使い、単純にファイル名を変更できるとは限らないということです。その理由は、DDLで作成される物理的な表は、キー付き物理ファイルが持てるのと同じ型のキーを持てるとは限らないからです。ですから、他の変更も行う必要があり、ある場合には以前行っていたように物理ファイルに直接アクセスする代わりに、適切なSQLインデックス（論理ファイル）を使用するように切り替える必要があります。
多くのRPGプログラマーが指摘する常に繰り返される問題は、DDLがファイル名と同じレコード様式名をもつファイルを生成することです。DDL（V5R4）とRPG(V6.1)の機能拡張で最近この問題は対処されましたが、RPGプログラムにとってずっと問題を引き起こしてきました。この大騒ぎを私達は完全に理解することは決してありませんでした。DDLを使ってレコード様式と同じ名前の表を作り、それからその表の名前を変えることは常に可能でした。正直なところ、それは追加ステップではありますが困難ではありません。
もう1つの課題は、SQLがビューやインデックスを完全に分離したものとして扱うことです。インデックスはキー付き論理ファイルであり、ビューはデータの再フォーマット、サブセット化、または結合用のキー無しの論理ファイルです。その結果、ビューにキーを定義することはできません。RPGでファイルを処理する場合、このキーの設定は一般的に望まれることなので、ビューの最も価値ある機能の多くが、ネイティブのI/O操作を使うプログラムでは殆どまたは全く使われません。
そうすべきか否か
それで、DDSの代りにDDLを使うという問いに対する答えはどうなるでしょう。どちらの方法にせよ、明らかに長所と短所があります。
DDLの制約のせいでDDLを使わないという、やむにやまれぬ理由が無い限り、新しいファイルを作るために、私達はDDLを使う傾向にあります。ビューの課題が問題であるなら、依然としてDDLで定義した表に対してDDSの論理ファイルを定義できることを忘れないでください。
既存の全ファイルをDDL定義の表に変えるというのはどうでしょうか？この考えと共同歩調を取るのに難渋しています。どんなパフォーマンス上の違いも、せいぜい微々たるもので、非常に状況固有のものです。データアクセスの多くが、ネイティブI/Oより埋め込みSQLを使って行われる場合には、DDL定義の表への変更は多分もっと有益です。
変更はそう見えるほど簡単な課題ではありません。わずかばかりの一般的な課題は、様式名およびビュー、インデックスおよびネイティブの論理ファイルの間の違いです。そう、回避方法は存在しますが、SQL同様ネイティブI/Oを使うすべてのRPGプログラムが依然としてデータを活用できるよう保証するのは簡単なことではありません。
その任務の複雑性を考えると、既存の物理ファイルの大半またはすべての大規模な変更の実施に費やされる時間と努力は、アプリケーションを改良する別な方法に費やした方が良いのではないかと疑問に思ってしまいます。明らかに、それぞれの組織はその独自の具体的な要求に照らしてこの判断を下す必要があります。
改変が価値ある努力だと判断した人々のために、私達がここで取り上げた多くの課題を含め、その課題を完全に自動化するツールの購入を検討したいと望むかもしれません。この仕事でその作業を減らすように設計されているツールで私達が知っている唯一の物はXcaseです。
あなたの下す判断に幸あらんことを！
