在现金流量报告中替换存储过程的想法

时间:2021-09-06 02:05:01

We have a Cash flow report which is basically in this structure:

我们有一个现金流量报告,基本上是这种结构:

Date |Credit|Debit|balance|
09/29| 20   | 10  | 10    |
09/30| 0    | 10  | 0     |

The main problem is the balance, and as we are using a DataSet for the Data, it's kinda hard to calculate the balance on the DataSet, because we always need the balance from the previous day.

主要问题是平衡,因为我们正在使用数据的DataSet,所以很难计算DataSet上的余额,因为我们总是需要前一天的余额。

Also this data comes from several tables and it's been hard to maintain this procedure, because the database metadata is changing frequently.

此数据也来自几个表,并且很难维护此过程,因为数据库元数据经常更改。

Anyone could give me some possible different solutions? for the problem?

任何人都可以给我一些不同的解决方案?对于这个问题?

This report is being displayed on a DataGrid.

此报告显示在DataGrid上。

3 个解决方案

#1


1  

This may be too big a change or off the mark for you, but a cash flow report indicates to me that you are probably maintaining, either formally or informally, a general ledger arrangement of some sort. If you are, then maybe I am naive about this but I think you should maintain your general ledger detail as a single table that has a bare minimum number of columns like ID, date, account, source and amount.

这对您来说可能是一个太大的变化或不合适,但现金流量报告向我表明,您可能正式或非正式地维持某种总分类账。如果你是,那么也许我对此很天真,但我认为你应该将总分类帐详细信息保存为单个表,其中包含最少的列数,如ID,日期,帐户,来源和金额。

All of the data that comes from different tables suggests that there several different kinds of events that are affecting your cash. To me, representing these different kinds of events in their own tables (like accounts receivable or accounts payable or inventory or whatever) makes sense, but the trick is to not have any monetary columns in those other tables. Instead, have them refer to the row in the general ledger detail where that data is recorded. If you enforce this, then the cash flow would always work the same regardless of changes to the other tables.

来自不同表格的所有数据表明,有几种不同类型的事件会影响您的现金。对我来说,在他们自己的表中表示这些不同类型的事件(如应收账款或应付账款或库存或其他)是有道理的,但诀窍是在其他表中没有任何货币列。相反,让它们引用总记录详细信息中记录数据的行。如果您强制执行此操作,那么无论其他表的更改如何,现金流都将始终如一。

The balance forward issue still has to be addressed and you have to take into account the number of transactions involved and the responsiveness required of the system but at least you could make a decision about how to handle it one time and not have to make changes as the other parts of your system evolve.

平衡转发问题仍然需要解决,你必须考虑所涉及的交易数量和系统所需的响应能力,但至少你可以决定如何处理它一次而不必改变系统的其他部分也在不断发展。

#2


0  

On the code side of things, you've got two relatively easy options, but they both involve iterating through the dataset.

在代码方面,你有两个相对简单的选项,但它们都涉及迭代数据集。

option 1: For loop prior to databinding. For each row in the datatable, add/subtract the credit/debits to the previous row's balance and assign it to the appropriate cell of your datatable.

选项1:用于数据绑定之前的循环。对于数据表中的每一行,将信用/借方加/减到前一行的余额,并将其分配给数据表的相应单元格。

Option 2: calculate during databinding. First you'd have a global variable that you could hold your value in. Set it to zero right before the databind. For each item or altitem, add/subtract the credit/debits to the global variable and assign it to the appropriate cell of your datagrid.

选项2:在数据绑定期间计算。首先,你有一个可以保存你的值的全局变量。在数据绑定之前将它设置为零。对于每个项目或altitem,将信用/借方加/减到全局变量,并将其分配给数据网格的相应单元格。

#3


0  

Be aware that this normally means great raise of network traffic, which can reduce the performance of the application as a whole (since you'd have to fetch all this data to process on the client).

请注意,这通常意味着网络流量的大幅增加,这会降低整个应用程序的性能(因为您必须获取所有这些数据以在客户端上处理)。

An alternative approach is creating a ( in what implementation you like) middle layer application which you can send a request and do this processing on the database server or in a separate network segment.

另一种方法是创建一个(在您喜欢的实现中)中间层应用程序,您可以在数据库服务器或单独的网段中发送请求并执行此处理。

If there is a SP to do this calculation, normally is because it touch a lot of data and the objective is to avoid this circulating in the network.

如果有SP进行此计算,通常是因为它触及大量数据,目的是避免这种情况在网络中传播。

#1


1  

This may be too big a change or off the mark for you, but a cash flow report indicates to me that you are probably maintaining, either formally or informally, a general ledger arrangement of some sort. If you are, then maybe I am naive about this but I think you should maintain your general ledger detail as a single table that has a bare minimum number of columns like ID, date, account, source and amount.

这对您来说可能是一个太大的变化或不合适,但现金流量报告向我表明,您可能正式或非正式地维持某种总分类账。如果你是,那么也许我对此很天真,但我认为你应该将总分类帐详细信息保存为单个表,其中包含最少的列数,如ID,日期,帐户,来源和金额。

All of the data that comes from different tables suggests that there several different kinds of events that are affecting your cash. To me, representing these different kinds of events in their own tables (like accounts receivable or accounts payable or inventory or whatever) makes sense, but the trick is to not have any monetary columns in those other tables. Instead, have them refer to the row in the general ledger detail where that data is recorded. If you enforce this, then the cash flow would always work the same regardless of changes to the other tables.

来自不同表格的所有数据表明,有几种不同类型的事件会影响您的现金。对我来说,在他们自己的表中表示这些不同类型的事件(如应收账款或应付账款或库存或其他)是有道理的,但诀窍是在其他表中没有任何货币列。相反,让它们引用总记录详细信息中记录数据的行。如果您强制执行此操作,那么无论其他表的更改如何,现金流都将始终如一。

The balance forward issue still has to be addressed and you have to take into account the number of transactions involved and the responsiveness required of the system but at least you could make a decision about how to handle it one time and not have to make changes as the other parts of your system evolve.

平衡转发问题仍然需要解决,你必须考虑所涉及的交易数量和系统所需的响应能力,但至少你可以决定如何处理它一次而不必改变系统的其他部分也在不断发展。

#2


0  

On the code side of things, you've got two relatively easy options, but they both involve iterating through the dataset.

在代码方面,你有两个相对简单的选项,但它们都涉及迭代数据集。

option 1: For loop prior to databinding. For each row in the datatable, add/subtract the credit/debits to the previous row's balance and assign it to the appropriate cell of your datatable.

选项1:用于数据绑定之前的循环。对于数据表中的每一行,将信用/借方加/减到前一行的余额,并将其分配给数据表的相应单元格。

Option 2: calculate during databinding. First you'd have a global variable that you could hold your value in. Set it to zero right before the databind. For each item or altitem, add/subtract the credit/debits to the global variable and assign it to the appropriate cell of your datagrid.

选项2:在数据绑定期间计算。首先,你有一个可以保存你的值的全局变量。在数据绑定之前将它设置为零。对于每个项目或altitem,将信用/借方加/减到全局变量,并将其分配给数据网格的相应单元格。

#3


0  

Be aware that this normally means great raise of network traffic, which can reduce the performance of the application as a whole (since you'd have to fetch all this data to process on the client).

请注意,这通常意味着网络流量的大幅增加,这会降低整个应用程序的性能(因为您必须获取所有这些数据以在客户端上处理)。

An alternative approach is creating a ( in what implementation you like) middle layer application which you can send a request and do this processing on the database server or in a separate network segment.

另一种方法是创建一个(在您喜欢的实现中)中间层应用程序,您可以在数据库服务器或单独的网段中发送请求并执行此处理。

If there is a SP to do this calculation, normally is because it touch a lot of data and the objective is to avoid this circulating in the network.

如果有SP进行此计算,通常是因为它触及大量数据,目的是避免这种情况在网络中传播。