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

2020-01-11

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

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の前にチェックを行うプロシージャの呼び出しを追加することになるだけです。