アカウント名:
パスワード:
だが、あえてバッチ処理した方が望ましい場合もあるわけで。たとえばネットを利用した振り込みとか、不正アクセスに勘付くためにあえてリアルタイム処理できなくしてる銀行もある。
古い技術は全否定するわけではなくて、要件に応じて使い分けることが必要。「新技術の方が優れている」は年中革新しないと気が済まない病に陥ったエンジニアの誤解。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
バッチ処理は時代遅れ (スコア:5, 興味深い)
だが、あえてバッチ処理した方が望ましい場合もあるわけで。
たとえばネットを利用した振り込みとか、不正アクセスに勘付くためにあえてリアルタイム処理できなくしてる銀行もある。
古い技術は全否定するわけではなくて、要件に応じて使い分けることが必要。
「新技術の方が優れている」は年中革新しないと気が済まない病に陥ったエンジニアの誤解。
Re:バッチ処理は時代遅れ (スコア:1)
言葉を整理すると、バッチ処理というのは、給与振込データとか自動振替データを何千、何万件貰ったとき処理するやり方。
銀行系のデータ処理には端末での1件処理、端末にcsvファイルとか読ませて1件処理を自動で繰り返す集合処理(ベンダーで言い方は色々あるだろうけど) 、センター側にデータ転送(レイアウトは全銀仕様とかもあるし、独自もあるかも)してセンターカット処理といってセンター側で一括処理する方法がある。とりあえずこの3つとして話を進める。
どれも同じ目的の入り口が違うだけなので、ほぼ同じ内容のデータベース更新になる(普通預金元帳とか通帳に印字する為の履歴とか、その他勘定更新もほぼ同じ)。
なので、普通に設計すればセンターカットも1件処理としてオンラインプログラムに渡して処理することになる。
バッチ処理そのものを無くすというのは意味が分からないけど、オンライン中にバッチ処理を回すというのは昔から有って、センターカット処理予約テーブルを用意して、予約テーブルを順に見てセンターカットを行いながら、ある口座への端末からの処理が来たときセンターカットが未処理なら、その口座の予約処理のみ先行処理してから端末処理を行うという方法がある。
たぶん、オンライン中のセンターカットを嫌うのはオンラインプログラムのパフォーマンスの問題だと思う。もしかすると最近のオンラインプログラムは、超並列に処理できるのが当たり前でみずほはそこが弱いとかあるのかもしれないけど、記事からは原因が全く見えないので、日経コンピュータとかが取材した記事を待つしか無いのでは。