DBエンジンを最大限に生かすバッチアプリの作り方：Oracle技術者のためのバッチアプリ開発講座（2）（3/3 ページ）

生産性とパーサ能力を最大限考慮した実装を極めよ

　最近のOracleのSQLパーサ（SQLの解析を行うエンジン）は、大変洗練されたデータアクセスの実行計画を作成してくれます。CASE式に限らず副問い合わせ（SELECT文が入れ子状態になったSQL）や表結合、集合演算、関数などを駆使した複雑なSQLであっても、最適なアクセスパスを選んで処理を行います。従って、複雑な処理を1つのSQLにまとめて記述した方が、処理時間の短い高性能のアプリケーションになる可能性が高いといえます。

　とはいえ、複雑な処理を1つのSQLにまとめて記述すれば、それだけ読みにくいコードになってしまいます。物事にはバランスが大切ですので、リスト2のような「結果セットを一括処理する方式」も併用しつつ実装効率と処理性能のバランスを考えることが重要です。

処理オーバーヘッドと可読性・生産性とのトレードオフ

　第1回目でも説明しましたが、バッチ処理のほとんどは定型的な処理の組み合わせにすぎません。定型処理を部品化してすべてのバッチアプリケーションで再利用すれば、品質の高いアプリケーションを簡単に大量生産することができます。そのためには、副問い合わせを多用した複雑なSQLを記述するよりも、部品化できる単純な単位で処理をつないでいく方式を採用することをお勧めします。具体的には、各定型処理のアウトプット（結果セット）を一時テーブルの形で保持し、次の定型処理へのインプットとするのです（図3）。

図3　一時テーブルによる処理の連結

　この方式では、各定型処理のアウトプットをいったん一時データとして保存する必要があるため、1つのSQLにまとめて記述する場合と比べてオーバーヘッドがあります。しかし、定型処理を部品化することには、SQLの再利用や自動生成が容易になるというメリットがあります。

　大規模なバッチ処理の開発では、似たようなアプリケーションを実装するケースがたくさんあります。生産性を向上させて品質の高いアプリケーションを簡単に大量生産するためには、定型処理を部品化して再利用するというスタンスが欠かせません。また、部品化した定型処理であれば、Excelの定義情報などからSQLを自動生成するような仕組みを準備するのもそれほど難しくはないでしょう。

　「定型処理の組み合わせでSQLを自動生成し、必要に応じて開発者が高度な処理を追加する」のが、最もバランスの取れた現実的な開発方式ではないでしょうか。

　今回は、Oracleデータベースを最大限に利用したバッチアプリケーションの実装テクニックについて解説しました。次回は、バッチアプリケーションに有効なOracleの機能について解説する予定です。