2-1.処理方式の検討～バッチ処理の入出力方式と処理結果の確認～
データの入出力方式
PL/SQLでバッチプログラムを開発する場合、データの種類や処理パターンに応じた実装方針を整理しておきます。
ここを設計者や開発者に依存させてはいけません。
前章で述べたように、”処理の構成に統一感を持たせること”は非常に重要な要素です。
よくある処理パターンとしては、次のようなパターンがあります。
- 外部データの取込み
ファイルから読み込んだデータをテーブルに格納するパターンです。 - 内部データの変換・加工
テーブルのデータを加工して別の表に登録するパターンです。 - 外部へのデータ出力
テーブルのデータをファイルに出力するパターンです。
いずれも極々ありふれた基本的な処理ですが、いざこれを集まった開発者の方々に設計～プログラミングをしてもらうと、様々なタイプの成果物が出来上がります。
例えばある人は、１つの処理でファイルからのデータを取込みながらデータの編集まで行ってしまうかもしれませんが、他の人は一旦ファイルレイアウト同じ構成のテーブルを作成し、次の処理で編集を行うように設計するかもしれません。
もしかしすると、プロジェクトマネージャはファイル取込み機能の開発コストを削減するために、ETLツールの導入を導入しているかもしれません。
この時点でメンバ間の認識相違があると、後で大きな手戻りが発生します。
いいえ、手戻ることができれば良いですが、表向きにはプログラムが動いているわけですから、稼働に向けて、このようなポイントが問題になって貴重な工数を割いて改修作業を行うことはなく、システムの土台が軟弱なシステムがそのまま稼働することになります。
ある処理はETLの設定を1ヵ所変更するだけで、テストも軽微で済んだのに、別の処理はプログラムの改修が必要となり、更にはファイルレイアウトとロジックに依存性があり、テスト工数も膨らんでしまう、という事態も考えられます。
通常であれば、処理の概要から大まかな改修コストを見積もることができますが、このように方式が初期開発時の担当者によってまちまちでは、実装まで調査を行わなければ見積もりができず、稼働後にシステムの改修を行う際の大きなデメリットとなります。
そのようなことにならないためにも、処理方式は要件を踏まえて事前に基本方針を定め、メンバ間で認識を合わせておく必要があります。
処理の起動及び結果確認方法
メインとなるデータの方式と同時に、必ず決めておかなければいけないこととして、処理の起動方式と処理結果の確認方式があります。
PL/SQLプログラムはOSコマンドから直接実行することはできず（C言語でコンパイルした実行形式ファイルや、Javaのjarファイルのような形式では保存できない）、OSシェルからSQL*Plusを介して実行する方法、OCIドライバを用いて他の言語から起動するといった方式が考えられます。
パッケージソフトのアドオン機能であれば、パッケージが提供する起動方式があるはずです。
また、オンラインバッチと呼ばれる画面からユーザーが手起動する方法もあります。
この場合も、どのような実装方針とするのか。これは画面の実装方針とも兼ね合わせて検討する必要があります。
これも、開発メンバ内で認識を統一しておく必要があります。
