技術的な質問ではなく、考え方についての質問です。
こっちを立てるとあっちが立たずのような状態で困ってます。

どのカテゴリで質問するか悩んだのですが、直近の投稿数が多いのでC言語のところで質問させて頂きます。
ご教示ください。

現在こういうバッチプログラムがあります。

バッチA
 > (1)外部から前日分の確定データリストを取得
 > (2)データリストに基づいて特定処理の実施
 > (3)特定処理の対象になったものをDB(テーブルA)に格納
※1つのプログラムで3つの処理を行ってます


今度、データリストの取得先に外部2が追加されます。
仕様が同じであれば、バッチAと同様のものを作ればいいのですが、
外部2の場合、1か月の間データが確定されないという仕様があります。
前日分のデータが確定するのは、
1カ月後までの間に取得するデータリストにキャンセルデータが無かった場合です。

1.そこでこのように考えました。

バッチA
 > 外部2から1カ月分のデータリストを取得
 > 取得データから、1か月前のデータを対象に1ヶ月間キャンセルデータが無いものを抽出する
 > (2)データリストに基づいて特定処理の実施
 > (3)特定処理の対象になったものをDBに格納


2.でも、毎日1か月分のデータを取得して抽出処理を行うのは負担になるし、
毎日ほぼ同じデータを取得するのはあほらしいと思い、以下のように考えました。

バッチA
 > 外部2から前日分のデータリストをDB(テーブルB)に格納
 > DBから1か月前のデータを対象に1ヶ月間キャンセルデータが無いものを抽出する
 > (2)データリストに基づいて特定処理の実施
 > (3)特定処理の対象になったものをDB(テーブルA)に格納


3.今度はそもそもバッチ分けた方がいいんじゃないかと思い、以下のように考えました。

バッチ1
 > 外部2から前日分のデータリストをDB(テーブルB)に格納
バッチA
 > DBから1か月前のデータを対象に1ヶ月間キャンセルデータが無いものを抽出する
 > (2)抽出したデータリストに基づいて特定処理の実施
 > (3)特定処理の対象になったものをDB(テーブルA)に格納


4.さらに、キャンセルデータの処理も別バッチにすれば、
  バッチAでの処理がわかりやすくなるじゃないかと思い、以下のように考えました。

バッチ1
 > 外部2から前日分のデータリストをDB(テーブルB)に格納
バッチ2
 > DB(テーブルB)から1か月前のデータを対象に1ヶ月間キャンセルデータが無いものを抽出する
 > 抽出したデータのキャンセルデータのレコードをDB(テーブルB)から削除
バッチA
 > (1)DB(テーブルB)から前日分のデータリストを取得
 > (2)データリストに基づいて特定処理の実施
 > (3)特定処理の対象になったものをDB(テーブルA)に格納


ここまで考えてどうするのがスマートなのかよくわからなくなってきてしまいました。
3か4でいこうと思うのですが、3の時にバッチAで抽出処理をするのはいまいちって思ってます。
それで4にしようと思ったのですが、
テーブルBは取得データをそのままの状態で入れておくって当初考えてたので、
それをあとからレコード削除したりするのもどうなんだろうと思ってます。
確定したデータと未確定のデータが混在するのもなんだか腑に落ちません。
それだったら、新たにテーブルCを作って、確定データを突っ込んでおくってことも考えたのですが、
そうなると、バッチA最後に格納しているテーブルAと何も変わらないようなものがもう一つできてしまいます。

どういうのがスマートというか良い考え方なのでしょうか。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

ああ、


1.データを取得する
1a.処理候補を選別する
の部分の無駄を削りたいという質問内容なんでしょうか?

データの取得に1か月分毎回取るのがあほらしいということであれば、
差分だけ取得して、過去にとったものとマージすればいいと思うけど。

処理候補の選別については、何らかのアルゴリズムを適用すれば
速くなると思うけれども、それだけ複雑になるわけで、
まずはシンプルなアルゴリズムで要求仕様を満たせるかどうか、
測定してみたらいいのではないでしょうか。

無駄は多いと思っても、シンプルな実装で要求仕様を満たせれば、あとあとのメンテが楽ですよ。
    • good
    • 0

説明が冗長で、現場の人(もしくは本人)しか理解できないような文章になってるよ。



ちょっと機能について簡単に整理すると、
1.データを外部から取得する
2.データを処理する
3.処理結果をデータベースに格納する
の3つなのでしょ?

で、1.の取得先が外部1と外部2からなるのかな。

2と3は取得先によらない処理?なら、そこは共通化してくくり出し、
手をつける必要がないようにしておく。

1.は取得先が増える可能性もあるので、そこだけ独立してメンテを行えるようにしておく。

パフォーマンスが問題になれば、1・2・3を1つずつチューニングする。
そうすれば、バグが起きても対応が容易。

というわけで、私なら、まずはメンテナンス性を重視します。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!


人気Q&Aランキング