`>I was refering to storing particular data in particular production tables which provides extra information when things go wrong. For example: I've had trouble with a client saying that the program didn't calculate the stock right. I've implemented a stock counter for each mutation that takes place. Thefore I'm able to track the stock trough time, but it also enables me to check if this value matches the stock field in the articles table. Besides stock information I hold some other information in other places. Once when the articles table crashed beyond repair, I was able to reconstruct the table by all information scattered troughout the system. I was able to do this because I denormalized tables. mostly for performance reasons but also for recovery purposes.
>

If you are worried about a single copy of business data being incorrectly calculated, what's the advantage of having two? What happens when one is correct and one is incorrect, and you don't know which? Seems to me like your first argument is an argument for denormalization to help with a possibly faulty software implementation. As for help with crash recovery- what's wrong with transactions and replication? If you are so worried about this, and have so much trouble with it, maybe you need to be using a server database...