There is a very practical reason why there is little historical data found in an application.
The reason for the paucity of historical data is the need for efficient transactional
performance. In a customer facing application, it is typical to do transactions. In order to
execute transactions quickly, it is necessary to wade through and process the minimum
amount of data. When an application stores massive amounts of historical data, the
efficiency of transaction performance is impeded. Therefore, online transaction
processing applications shed as much data as possible as soon as possible. In doing so,
they optimize the performance of the system.
In order to understand this principle, consider your bank account in the bank. Is it
reasonable for you to find the current account balance? Yes, of course it is. Is it
reasonable for you to go and look up a transaction that you made last week? The answer
is yes, of course. Now, suppose you are going through an IRS audit. Suppose you need to
find a check you wrote 5 years ago. Is it reasonable that the 5-year-old check is in the
online processing portion of your database? No, it is not reasonable. In order to find your
5-year-old check, the bank will have to look through audit and archive records.
When it comes to detail, applications typically store a month's worth of data or maybe
even a quarter's worth of data depending on the nature of the business being
accommodated. Beyond that, the data are stored elsewhere.
Fig. 5.1.7 shows that online transaction processing applications focus on very current
information.
Chapter 5.1: The Siloed Application Environment