In a data warehouse implementation, million and million of data could be processed every single minute and millions more get shared from data source to another.

Dealing alone with the current value of the data may benefit a company by having to expend on less on additional software and hardware acquisition but more often, investing on dealing with the historical perspective the data within the data warehouse can have more benefit not having a historical database.

True, having a historical database means that a business organization will have to buy additional computer servers with more computing power, random access memory and larger storage because processing the historical perspective of data can really a daunting and labor intensive work. But in the long run, the return of investment can be surprisingly big.

In the world of information technology, time moves so fast. It is not surprising that a new gadget, say a cellular phone, which costs a thousand dollars today may depreciate to a few hundred dollars within the next six month because technology innovation brings in new models at very short intervals. The same could be true in dealing with data. The volume of data being dealt with today will be surely become a distant history by the next day.

Keeping a historical database has a lot of advantages. One of the biggest advantages is that there can a performance monitor in the operation of the entire data warehouse so that the system can be given early treatment should a problem be detected and a corresponding diagnosis has been identified.

The performance monitor is a very valuable tool which can help eliminate troublesome profit destroyers such as oscillations and swings.

Because a historical database provides a historical perspective on the data, it would be very easy to troubleshoot problems that occur in the system. For instance, if an output data no longer reflects the business rules algorithm, there would be two ways to verify the cause of the problem.

The first would be to check for the code logic for any logical bug. And if there is no problem with the code, the other methods would be to check the value of the data entered.

In any database or programming implementation, a data may not cause an immediately problem so a currently emerging problem may have been cause by some data entered in the past. With a problem like this, the solutions would definitely come from the historical database.

A historical database is also very useful in spotting trends and patterns about the operations of the company and how well the company is performing compared to ther players in the same industry.

A data warehouse is generally a repository of two things: historical data and current transactional data. Of course, if any company wants to see a trend, for instance, in the sales performance of a particular item, it does not only try to spot the pattern from a very short period.

In fact, most companies will want to see a "panoramic" view of a performance not just one item but of all the items and all the business events and transactions including the trending in sales, income, human resource, manufacturing all other facets of the business. So going back to the trending in the sale of a particular item, the data to be considered may include sales from as far back as two years. Data from this past are already stored in the historical database so as to overload the current transactional database.

A historical database is usually in compresses format because unlike the current transactional, the historical database is less frequently accessed.