Most recent edit on 2007-09-17 21:03:47 by InformaPlus [c5]
Additions:
In 'Example 1' above, such batch process could be called from the Task Prefix. This would result in recalculating a starting ‘Running Total’ every time the process starts before any user interaction.
Deletions:
In our example, such batch process could be called from the Task Prefix. This would result in recalculating a starting ‘Running Total’ every time the process starts before any user interaction.
Edited on 2007-09-17 21:01:07 by InformaPlus [C4]
Additions:
1) As in the ‘Example 2’ that we will present further, the ‘Running Total’ can be saved in the database on a summary row of the same or another table. In which case it becomes a persistent Real field. Such persistent Real field is a form of “De-Normalization” in relational database terms. However, it can be justified in some cases where the volume of details to process is massive or when the presentation order would depend on the ascending or descending order of many ‘Running Total’ values. A persistent (Real) ‘Running Total’ can be a segment of a pertinent index that can expedite the time that it takes to present the information in the required order.
Deletions:
1) As in the ‘Example 2’ we that will present further, the ‘Running Total’ can be saved in the database on a summary row of the same or another table. In which case it becomes a persistent Real field. Such persistent Real field is a form of “De-Normalization” in relational database terms. However, it can be justified in some cases where the volume of details to process is massive or when the presentation order would depend on the ascending or descending order of many ‘Running Total’ values. A persistent (Real) ‘Running Total’ can be a segment of a pertinent index that can expedite the time that it takes to present the information in the required order.
Edited on 2007-09-17 20:59:13 by InformaPlus [C3]
Additions:
1) As in the ‘Example 2’ we that will present further, the ‘Running Total’ can be saved in the database on a summary row of the same or another table. In which case it becomes a persistent Real field. Such persistent Real field is a form of “De-Normalization” in relational database terms. However, it can be justified in some cases where the volume of details to process is massive or when the presentation order would depend on the ascending or descending order of many ‘Running Total’ values. A persistent (Real) ‘Running Total’ can be a segment of a pertinent index that can expedite the time that it takes to present the information in the required order.
A business case example of such pertinent ‘Running Total’ could be a ‘Total Sales to Date’ figure for each customer in a Customers table. Let’s say that there would be a need to display an online list of customers in descending order of ‘Total Sales to Date’. In this case, it would be typically much faster to have the Total sales figures of each customer on the Customers table with an index in descending order of this column. This would save a lot of processing due to recompiling such figures for all customers and having to do a sort before being able to display the end result.
2) Saving ‘Running Totals’ is sometimes justified. However, with a reasonably planed scope of details to summarize coupled with today’s power of database processing, there is often no need to de-normalize ‘Running Totals’ information. In many cases a batch task can be created to read all the details and accumulate the total if and when the total is required. Note that such batch task does not use an incremental update but a regular update in its Record Suffix such as:
Deletions:
1) As in the ‘Example 2’ we will present further, the ‘Running Total’ can be saved in the database on a summary row of the same or another table. In which case it becomes a persistent Real field. Such persistent real field is a form of “De-Normalization” in relational database terms. However, it can be justified in some cases where the volume of details to process is massive or when the presentation order would depend on the ascending or descending order of many ‘Running Total’ values. A persistent (Real) ‘Running Total’ can be a segment of a pertinent index that can expedite the time that it takes to present the information in the required order.
A business case example of such pertinent ‘Running Total’ could be a ‘Total Sales to Date’ figure for each customers in a Customer table. Let’s say that there would be a need to display an online list of customers in descending order of ‘Total Sales to Date’. In this case, it would be typically much faster to have the Total sales figures of each customer on the Customers table with an index in descending order of this column. This would save a lot of processing due to recompiling such figures for all customers and having to do a sort before being able to display the end result.
2) Saving Running Totals is sometimes justified. However, a reasonably planed scope of details to summarize coupled with the power of database processing, there is often no need to de-normalize ‘Running Totals’ information. In many cases a batch task can be created to read all the details and accumulate the total if and when the total is required. Note that such batch task does not use an incremental update but a regular update in its Record Suffix such as:
Oldest known version of this page was edited on 2007-09-17 20:50:34 by InformaPlus [IU Persistence]
Page view:
Running Total Persistence:
The incremental logic is powerful, yet it must typically be coupled with some additional support to make the ‘Running Total’ persistent. The Running total must either be saved with the details or re-calculated every time the details are accessed in order to have a starting value that is synchronized with the details.
In the previous example, exiting the program and re-executing it will lead to an inaccurate value of the ‘Running Total’ since the virtual value of the ‘Running Total’ is lost (not persistent) upon exiting the program. Two things can be done to correct this situation:
1) As in the ‘Example 2’ we will present further, the ‘Running Total’ can be saved in the database on a summary row of the same or another table. In which case it becomes a persistent Real field. Such persistent real field is a form of “De-Normalization” in relational database terms. However, it can be justified in some cases where the volume of details to process is massive or when the presentation order would depend on the ascending or descending order of many ‘Running Total’ values. A persistent (Real) ‘Running Total’ can be a segment of a pertinent index that can expedite the time that it takes to present the information in the required order.
A business case example of such pertinent ‘Running Total’ could be a ‘Total Sales to Date’ figure for each customers in a Customer table. Let’s say that there would be a need to display an online list of customers in descending order of ‘Total Sales to Date’. In this case, it would be typically much faster to have the Total sales figures of each customer on the Customers table with an index in descending order of this column. This would save a lot of processing due to recompiling such figures for all customers and having to do a sort before being able to display the end result.
2) Saving Running Totals is sometimes justified. However, a reasonably planed scope of details to summarize coupled with the power of database processing, there is often no need to de-normalize ‘Running Totals’ information. In many cases a batch task can be created to read all the details and accumulate the total if and when the total is required. Note that such batch task does not use an incremental update but a regular update in its Record Suffix such as:
Update Running Total = Running Total + Value, How=Normal.
In our example, such batch process could be called from the Task Prefix. This would result in recalculating a starting ‘Running Total’ every time the process starts before any user interaction.
It is ultimately the choice and responsibility of the developer to decide which is the most appropriate way to maintain persistence of incremental values. eDeveloper efficiently accommodate both options above.
Back To:
Incremental Update
The original version of this page was provided by: InformaPlus
