- ベストアンサー
ORACLE,VB6を使った家計簿ソフトの開発 - 家計を管理するための簡単なプログラム
- ORACLE,VB6を使って家計簿ソフトを開発しています。コンボボックスやテキストボックスを使って登録日、明細区分、グループ、備考、金額を入力し、SPREADシートに追加していきます。また、登録日の入金合計、出金合計、残高を計算して登録します。過去の残高の修正やデータの登録によって現在のデータが変わってしまう問題についても悩んでいます。
- 過去の残高修正によって現在のデータが変わる問題について、どのように処理すればよいのか悩んでいます。過去の残高を修正した場合、それ以降のデータの残高を一つ一つ再計算して登録し直す必要があるのでしょうか？データベース上で一括で残高を書き換える方法はあるのでしょうか？また、Ｄ日付データテーブルに残高を持たせるのが適切なのかも検討したいです。
- ORACLEとVB6を使って家計簿ソフトを開発しており、登録日、明細区分、グループ、備考、金額を入力し、SPREADシートに追加しています。また、登録日の入金合計、出金合計、残高を計算して登録します。問題として、過去の残高修正によって現在のデータが変わることがあるため、どのように処理すればよいのか悩んでいます。一括で残高を書き換える方法や、Ｄ日付データテーブルに残高を持たせるべきかも検討したいと考えています。
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
構造は、使い方に依存すると思うので、考え方のみ。 まず、データと現実をどのように整合さしているかがひとつのポイントになると思います。 たとえば、昨日のデータを昨日登録したとします。登録した限りは、現実のお財布の中身は、データとあっていたはずです。（たとえダミーを入れようが使途不明金で計上しようが、あっていなきゃおかしいですよね。） そして、今日のデータを入力します。当然、やはり、今日のデータ上の残高と財布の中身はあっているはずです。 ここで、昨日のデータを修正しました。 残高に影響するような修正をする羽目になったということは、 ・昨日の締めの作業が間違えていた。（つまり、昨日の残高が嘘だった。） ・使途不明金の正体が発覚した。 のどちらかのはずです。 もし、前者だとしたら、これは、もう、それ以降のデータが全部影響を受けるのはしょうがないですよね。計算し直すべきです。 後者だとすれば、使途不明金と、発覚して登録したデータとの差し引きは０になり、締めのデータは影響を受けない。つまり、今日のデータへの余波はないはずです。 というわけで、私が同じようなソフトを作ったときには、日次（月次）の締めようのテーブルを別途構築しました。 会社の会計と同じです。棚卸し（つまり、財布の中身とデータの照合）をしたときに、ソフト上で締めの作業をするわけです。そのときに、その日（月）の残高を締めテーブルに登録します。 今日（今月）の残高を計算するときには、締めテーブルの残高を基礎にして計算します。 もし、締めテーブルに波及するような過去データの修正をやったら、もう一度、それ以降のすべての日（月）の締め作業はやり直すべきですから、計算をやり直します。（そのためのメニュー項目かボタンと、その処理ルーチンは当然必要です。） もし、プラスマイナスで相殺する修正なら締めの作業は別にやり直す必要もありません。 もっとも、前回の締め程度ならともかく、それ以前の締めデータにまで波及する修正が入るとなると・・・・現実の世界（財布）はどうなっていたかを考えると・・・それってどんぶり勘定？（笑）というわけで、普通は、締め作業のやり直しはそんなに大量のデータにはならないはずですよね。
お礼
なるほど！！ そういう考え方があるんですね。 非常に参考になりました。早速試してみます！ ご丁寧な説明ありがとうございました。