3-5.実装方針の検討~バッチ処理の構成~

これまでの内容を総合すると、バッチプログラムは自ずと決まり切った構成になってきます。
処理の流れとしては、

  1. 初期処理
    変数の初期化とデータの削除
  2. データの読み込み
  3. データの書込み
    ※場合によっては(INSERT~SELECTを使用する場合)読み書きが同一処理の場合もある。
  4. 終了処理
    処理結果のログ出力

となるでしょう。

忘れてはいけないのは、実装に際しては、PL/SQLパッケージ内部のプロシージャを、このままの順序で書いてはいけないということです。

パッケージでの実装は下記のように逆順で記述します

CREATE OR REPLACE PACKAGE BODY sample_package
IS
  PROCEDURE finalize
  IS
  BEGIN
   :
  EXCEPTION
    WHEN OTHERS THEN
      RAISE;
  END finalize;
--
  PROCEDURE insert_data
  IS
  BEGIN
   :
  EXCEPTION
    WHEN OTHERS THEN
      RAISE;
  END insert_data;
--
  PROCEDURE get_data
  IS
  BEGIN
   :
  EXCEPTION
    WHEN OTHERS THEN
      RAISE;
  END get_data;
--
  PROCEDURE init
  IS
  BEGIN
   :
  EXCEPTION
    WHEN OTHERS THEN
      RAISE;
  END init;
--
  PROCEDURE main
  IS
  BEGIN
    init;
    get_data;
    insert_data;
    finalize;
  EXCEPTION
    WHEN OTHERS THEN
      RAISE;
  END main;
END sample_package;

注目すべきポイントは、外部からの読み出し元となるプロシージャmainが最後に記述されていることです。

そして処理する順番に「下から」記述しています。
これは、PL/SQLの言語仕様で、コンパイル時に上から読み込んでいき、既に読み込まれたプロシージャしか呼び出せないからです。

可読性という意味では、処理順がわかりづらくデメリットになるのではと思われるかもしれませんが、そもそも可読性を上げるために、プログラムをモジュール化しプロシージャを分けているはずです。

mainプロシージャの記述内容で、処理順と処理概要がわかるようになっていることが重要なポイントです。

プログラミングの際にはこの構成をベースに考えます。
仕様が複雑になっていっても考え方は変わりません。
他のテーブルへのINSERTが増えれば、mainから呼び出すプロシージャを追加することになりますし、INSERT時にチェックを行う必要が出てきたら、INSERTの前にチェックを行うプロシージャの呼び出しを追加することになるだけです。

 

Posted by tfurukaw