銀行の残高
銀行の残高データって、その銀行内で
支店番号＋口座種別＋口座番号毎に「最終残高」を保持しているのですかね？
「最終残高」だけを管理するデータは存在せずに、
支店番号＋口座種別＋口座番号＋日付＋連番毎に、
取引前残高、入金額、出金額、取引後残高を持っているのですかね？
販売管理の売掛残高や商品残数の管理だと、数日前の売上額に訂正があった時など
残高の計算のやり直しなんかやる事があります。
売掛残にしても、在庫残にしても、
コード＋年月：前月残、今月の増、今月の減、今月残
といった残管理が主目的の集計データを作っております。
いずれにせよ、いつ時点の残高はいくつだったというデータは必ず必要な訳で
それを年度で持つか、月初で持つか、月末で持つか、毎日持つかの違いなの
でしょうね。
月次で管理する作りばっかりやっているので、今のやり方がベスト解なのか疑問で。
食品製造関連だと、日別に残数を持つ作りを見た事もあります。
-
何がベストかは難しいですね
今まで作成したシステムは
基本的に月次更新等で確定数字が必要なので月次更新は必要ですね
あとはリアルデータを持つか持たないか
特定日までは月次と履歴等で計算できるようにするのかなと
銀行等は前のデータを修正する事がないような気がしますので
その時の残高を持っているとかですかね（やったことがないので推測ですが・・・）
-
こんにちはＰｕです
なんせよ疑問を持つ事は大事ですね
銀行の場合かなり昔からオンライントランザクションを処理するプロセッサー(OLTP)ベースの考え方で
insertオンリーで訂正と言う概念はなかったと思います（知らんけど(^_-)-☆）
ですので取引明細とは別に最終残高があれば事足りると思います（知らんけど(^_-)-☆）
会計の考え方からすれば一般の販売管理でもデータ訂正はせず、赤黒のデータを発生させる方が
正しい考え方だと思います（利便性を考えなければ）履歴が残るので。
あくまでも私個人の考え方です。
でわ～でわ～ -
ISHIJIMAさん、Puさん いつも大変お世話になっております。
早速ご意見頂き誠にありがとうございます。
銀行の残高の件は意見は一致した感じですね。
販売管理での理論在庫数は、リアルタイムに求められる事が多いです。
レコードロックやシステムアボートが絶対起きないシステムを作れた事もありませんし
リランで再計算してもらうファイル構造等を取る事が多いです。
在庫数は年初分しか保持せずに
1月1日～指定日までの入出荷を差し引きしたSQL文で現在理論在庫数を都度求める！
なんてのも有りなのかなと、以前のISHIJIMAさんの投稿をヒントに思った事もあります。 -
>レコードロックやシステムアボートが絶対起きないシステムを作れた事もありませんし
遅延トランザクションで実現可能ですよ
-
私の場合、（遅延ではなく）タスク前トランザクションを行う事により
デッドロックを起こしてしまう事がありそうです。
田中さんが商品のＡとＢとＣとＤを出荷する伝票を保存し、同時に
山田さんが商品のＤとＣとＢとＡを出荷する伝票を保存した場合に
拠点別＋商品コード＋年月別の残管理データのデッドロックとか。
遅延トランザクションの場合、絶対にデッドロックは起きないのでしょうか？ -
>デッドロックを起こしてしまう事がありそうです。
>拠点別＋商品コード＋年月別の残管理データ
デッドロックはまた別の話のような気がします。
ただ残高管理データ等があるとDB構造及び更新の方法を考えないといけないかもしれません。
-
承知しました。ご返信ありがとうございました。
-
Puさん
> 銀行の場合かなり昔からオンライントランザクションを処理するプロセッサー(OLTP)ベースの考え方で
> insertオンリーで訂正と言う概念はなかったと思います昔、35年くらい前になりますが、オフコン上がりの知り合いがいて、レコードを一切修正せず、レコードの追加だけで履歴を残す作りのプログラムばかりを作る人がいて、当時は奇異に感じていたのですが、そういう事情があったんですね（笑
-
私は1982年に出たCondor S20から始まって、dBASE II→dBASE III→dBASE III Plus→dbMAGIC→Magicと流れてきたのですが、今になって、なんだかそのInsertオンリーの作りというものに興味が沸いてきました。今度、作ってみたいと思います。
-
トランザクションはコミットするまでは途中で問題があった場合は
すべてロールバックされると思っています。
遅延でも物理でも問題ないかと思います。
ただトランザクションの範囲が広い場合は範囲とかDB構造を検討して
デッドロックが起きないようにする事が重要だと思っています。
ただ遅延の場合はトランザクション内で更新する前に更新されている場合は
（デットロックがかかるような更新）
エラーとなって画面に戻ってくるので再度実行する事ができると思っています。
>田中さんが商品のＡとＢとＣとＤを出荷する伝票を保存し、同時に
>山田さんが商品のＤとＣとＢとＡを出荷する伝票を保存した場合にこの様な場合は両方ともエラーとなって戻ってくると思っています。
再度同時に実行すればまた両方エラーとなり同時に実行されるのであれば無限にエラーとなると思います。
ただ同時に何回もされるような事は実際ないので問題のではないかと思っています。
違っていたらすみません。
-
ISHIJIMAさん アドバイス大変ありがとうございます。
ひとまずお礼申し上げます。
実験など行っていきたいと思います。 -
ある書籍からの引用。
金融系のシステムでよく使われる処理としては、削除処理も打ち消しのINSERTとして保存し、合計値を算出する設計とすることもあると書かれていました。 -
こんにちはPuです。
そもそも大昔は大量のデータからそのデータを探すのに時間が掛かったんです
一番早いのはデータのinsertでした
データ訂正の場合1:元のデータを削除,2訂正後のデータをinsert
これも削除の為元のデータを探さないといけません（削除はデータ先頭にFFをupdateする)なので
訂正なんです。
ですので訂正も赤伝（マイナスデータ）をinsertして訂正後のデータをinsertすると言う作りが
残高更新も加算だけで済みますのでプログラムもシンプルになります。
シンプルであると言う事は処理も軽く（プログラムステップ数も少ない）、バグも出にくい
日本人Eは複雑な事をより複雑にする事は得意なんですが
複雑な事をシンプルに考えると言うのが苦手な人種なんですかね
日本のテレビのリモコンがその代表ですね(;^_^A
その複雑さをマニュアルでカバーしようとする
マニュアルなんかがなくても大丈夫と胸を張れるシステムを目指したい今日この頃
「シンプルであることは、複雑であることより難しい」
でわ～でわ～ -
ありがとうございます。
> 1:元のデータを削除,2訂正後のデータをinsert
各種伝票入力の明細行数の分だけ、実データ明細DELETE、
WFから実データへINSERTこの処理を行っています。
物によっては実データを直メンテ、保存したくない場合はRollbackする作りにする事もあります。
お客様の要望を聞くと、そんな風に考えているんだとシンプルにしたくなる事があります。 -
私は、40年以上前は汎用機やオフコンの利用者側の経験しかありませんでしたので、当時そんな事情があったとは知りませんでした。勉強になりました。
-
私は26年位前迄はNECのオフコン、ビジネスパソコンを使っていました。
COBOLだったので、READ INVALID、READ NEXT、WRITE、REWRITE、DELETEを記述しておりました。
Magicの書き込みリンクは、READ INVALIDとWRITE、REWRITEの組合せなんだと理解するなどしてました。 -
ビジネスパソコンは８インチでOS起動して、取りだして、エディタ動かして
コンパイルして、リンクして、実行して・・・なんて事やってましたね。
それはさすがに30年以上前の話ですけど。 -
そうですね、30年くらい前から、COBOLからdbMAGICに転向してこられた方が多かったですね。今でも記憶にあります。
-
8インチでの起動は、当時のCP/M-86やMS-DOSのパソコンでもありましたね。今でも8インチディスクは記念に取ってあります（笑
サインインしてコメントを残してください。
コメント
19件のコメント