FiletoDBのバッチ処理に関する備忘録

駆け出しのSEです。

今回初めてバッチ処理の設計・実装に取り組みましたが、FiletoDBのバッチ処理において、ファイルからDBへデータが格納される流れを理解するにあたって少し混乱があったので、ここに書き留めておきます。

扱うファイルの構成について

ファイルの中身は、ヘッダレコード、データレコード、トレーラレコードなど、「レコード」という単位でデータ項目がグループ分けされています。
なお、ファイル自体は固定長改行無しのテキストファイルを意識していますが、そこからデータ項目を抽出していく過程については割愛します。
今回は、とある会員情報を題材とした以下のような1つのファイルを例に処理を説明します。
ここでは、レコードの種類はデータ区分という項目で識別します。

ヘッダレコード

データ区分	会員番号	氏名
1	1111	ﾀﾅｶｲﾁﾛｳ

データレコード

データ区分	生年月日	電話番号	メールアドレス
2	20001231	11122223333	[e-mail]

トレーラレコード

データ区分	会員ランク	ポイント
8	GOLD	300

DB登録後の状態

以下にDB登録後の状態を示します。
レコードには登録順に処理連番を振り、テーブル項目として追加するものとします。
なおここで、ファイルのレコード種類の「レコード」と、DBの行を表す「レコード」は区別するよう注意してください。

処理連番	データ区分	会員番号	氏名	生年月日	電話番号	メールアドレス	会員ランク	ポイント
1	1	1111	ﾀﾅｶｲﾁﾛｳ
2	2			20001231	11122223333	[e-mail]
3	8						GOLD	300

上記のように、基本的にファイルのレコード種類をひとつの単位として処理し、対応する項目ごとに登録を行っていくことで、ファイルのレコード種類ごとにDBの1レコードとなります。（表で見ると階段状にデータが入るイメージ）
つまり、DBに登録した状態でも、「ヘッダレコード出身の行」「データレコード出身の行」が存在するイメージで、これ以降にDBtoDBの処理が続く場合も、この単位のまま精査などを行っていくのが一般的です。
なお、該当するレコード種類以外の行に絶対に格納しないかというとそうではなく、その必要がある際はインスタンス変数やセッションで持ち回ることで対応します。

私が設計書を読み始めたときは、なんとなく1ファイル分のデータは自動的にDBの1行として登録されるかのように思い込んでいたので、今回このように書き留めておくことにしました。

※このアカウントで発信する内容はあくまで私個人の意見であり、現在所属する会社の公式見解を示すものではありません。