ORACLE,VB6を使った家計簿ソフトを作ってます

質問

初めて投稿させていただきます。
プログラム暦半年の者です。
今年の春から未経験でソフト開発の会社で研修を受けたり雑用したりしています。

現在開発言語にVB6.0、データベースにORACLE8を使って個人的に家計簿ソフトを作っています。

コンボボックスやテキストボックスを使い
・登録日

・明細区分(入金or出金)　
・グループ(入金→給与,仕送　/ 出金→家賃,光熱費)
※別マスター登録プログラム有り
・備考
・金額

を入力し、SPREADシートに追加していき、登録日の入金合計、出金合計、残高を計算して登録するという簡単なプログラムです。

テーブル構成は

Ｍ明細区分(detailkbn_no, detailkbn_name)
Ｍグループ(detailkbn_no, group_no, group_name)
Ｄ日付データ
(target_day --登録日,
get_total 　--入金合計,
spend_total --出金合計,
balance --合計 )
Ｄ明細
(target_day --登録日,
detail_no --明細No,
detail_kbn --明細区分No,
group_no --グループNo,
note --備考,
amount --金額 )

という感じです。

メインのフォームでは
Ｄ日付データ
Ｄ明細
にデータを登録するのですが,残高の計算は現在

前登録日残高 + (現登録日入金合計 - 現登録日出金合計)

としています。
しかしこれでは残高が過去の残高に依存しているので、過去の残高を修正したり過去のデータを登録したりすると現在のデータが変わってしまいます。

こーいう場合はどのように処理したらよいのでしょうか？？

過去の残高を修正した場合はそれ以後のデータの残高を一つ一つ再計算して登録し直すしかないのでしょうか？？
（データ件数が増えた場合に非常に時間がかかってしまいそうです…）　

データベース上で一発でそれ以降のデータの残高を書き換えるなんてことは不可能なのでしょうか？？

そもそもＤ日付データテーブルに残高というフィールドをもたせたことに無理があるのでしょうか？？
(登録日でグループ化したSUM(入金合計)-SUM(出金合計)を残高として表示させるだけにするとか…)

長々と申し訳ありませんでした。
説明が足らない部分も多々あるとは思いますが理解できる範囲で結構ですのでどなたかご教授いただけると助かります。

よろしくお願いします。

回答No.1

mitoneko · ベストアンサー

構造は、使い方に依存すると思うので、考え方のみ。
　まず、データと現実をどのように整合さしているかがひとつのポイントになると思います。
　たとえば、昨日のデータを昨日登録したとします。登録した限りは、現実のお財布の中身は、データとあっていたはずです。（たとえダミーを入れようが使途不明金で計上しようが、あっていなきゃおかしいですよね。）
　そして、今日のデータを入力します。当然、やはり、今日のデータ上の残高と財布の中身はあっているはずです。

　ここで、昨日のデータを修正しました。
　残高に影響するような修正をする羽目になったということは、
・昨日の締めの作業が間違えていた。（つまり、昨日の残高が嘘だった。）
・使途不明金の正体が発覚した。
　のどちらかのはずです。
　もし、前者だとしたら、これは、もう、それ以降のデータが全部影響を受けるのはしょうがないですよね。計算し直すべきです。
　後者だとすれば、使途不明金と、発覚して登録したデータとの差し引きは０になり、締めのデータは影響を受けない。つまり、今日のデータへの余波はないはずです。

　というわけで、私が同じようなソフトを作ったときには、日次（月次）の締めようのテーブルを別途構築しました。
　会社の会計と同じです。棚卸し（つまり、財布の中身とデータの照合）をしたときに、ソフト上で締めの作業をするわけです。そのときに、その日（月）の残高を締めテーブルに登録します。
　今日（今月）の残高を計算するときには、締めテーブルの残高を基礎にして計算します。

　もし、締めテーブルに波及するような過去データの修正をやったら、もう一度、それ以降のすべての日（月）の締め作業はやり直すべきですから、計算をやり直します。（そのためのメニュー項目かボタンと、その処理ルーチンは当然必要です。）
　もし、プラスマイナスで相殺する修正なら締めの作業は別にやり直す必要もありません。
　もっとも、前回の締め程度ならともかく、それ以前の締めデータにまで波及する修正が入るとなると・・・・現実の世界（財布）はどうなっていたかを考えると・・・それってどんぶり勘定？（笑）というわけで、普通は、締め作業のやり直しはそんなに大量のデータにはならないはずですよね。

お礼

なるほど！！
そういう考え方があるんですね。
非常に参考になりました。早速試してみます！
ご丁寧な説明ありがとうございました。