基本的にこの構造のキャッシュ フロー レポートがあります。
Date |Credit|Debit|balance|
09/29| 20 | 10 | 10 |
09/30| 0 | 10 | 0 |
主な問題は残高です。Data に DataSet を使用しているため、前日の残高が常に必要になるため、DataSet で残高を計算するのはちょっと難しいです。
また、このデータは複数のテーブルから取得され、データベースのメタデータが頻繁に変更されるため、この手順を維持するのは困難です。
誰かが私にいくつかの可能な異なる解決策を教えてもらえますか? 問題のために？
このレポートは DataGrid に表示されています。
これはあなたにとって大きすぎる変更であるか、的外れであるかもしれませんが、キャッシュ フロー レポートは、あなたがおそらく公式または非公式に何らかの総勘定元帳の取り決めを維持していることを示しています。もしそうなら、私はこれについて素朴かもしれませんが、総勘定元帳の詳細を、ID、日付、アカウント、ソース、金額などの最小限の数の列を持つ単一のテーブルとして維持する必要があると思います.
さまざまなテーブルから得られるすべてのデータは、現金に影響を与えるいくつかの異なる種類のイベントがあることを示唆しています。私にとって、これらのさまざまな種類のイベントを独自のテーブル (売掛金、買掛金、在庫など) で表現することは理にかなっていますが、秘訣は、それらの他のテーブルに金銭的な列を持たせないことです。代わりに、そのデータが記録されている総勘定元帳の詳細の行を参照してもらいます。これを強制すると、他のテーブルへの変更に関係なく、キャッシュ フローは常に同じように機能します。
繰越残高の問題にはまだ対処する必要があり、関連するトランザクションの数とシステムに必要な応答性を考慮する必要がありますが、少なくとも 1 回の処理方法について決定を下すことができ、変更を加える必要はありません。システムの他の部分が進化します。
これは通常、ネットワーク トラフィックが大幅に増加することを意味し、アプリケーション全体のパフォーマンスが低下する可能性があることに注意してください (クライアントで処理するには、このすべてのデータを取得する必要があるため)。
別のアプローチは、リクエストを送信し、データベースサーバーまたは別のネットワークセグメントでこの処理を実行できる中間層アプリケーションを作成することです (どのような実装を好むか) 。
この計算を行う SP がある場合、通常は、多くのデータに触れるためであり、目的はネットワーク内での循環を回避することです。
コード側では、比較的簡単なオプションが 2 つありますが、どちらもデータセットを反復処理する必要があります。
オプション 1: データバインディング前の for ループ。データテーブルの各行について、貸方/借方を前の行の残高に加算/減算し、それをデータテーブルの適切なセルに割り当てます。
オプション 2: データバインディング中に計算します。まず、値を保持できるグローバル変数を用意します。データバインドの直前にゼロに設定します。各項目または項目について、クレジット/デビットをグローバル変数に加算/減算し、データグリッドの適切なセルに割り当てます。