In most cases, calculations should be done in queries. That way if any of the operand values change, the result changes. A good example of what not to store is AGE.
You can calculate Age in a query so if you want to select only people who are between 18 and 26, that is easy enough. However if you calculate Age and store it. Tomorrow, some of your records will be incorrect because anyone who had a birthday today will be one year older tomorrow. The situation is less obvious in other cases but the rules of normalization warn against storing any data that is not 100% dependent on the primary key. So Age is dependent on two things - DOB and today's date. DOB is dependent on the person but today's date changes every day and so you can't store it.
Another situation is if you have a startDate and EndDate in the same record. You can always calculate the difference in a query. If you store the difference in the record, it wastes space and you have to be absolutely certain that any place either date could be changed will also force the recalculation of the difference. This leaves a gaping hole and if the programmer is even a little sloppy or a new person takes over the app and doesn't recognize the danger, he may create a new procedure and not understand the ramifications of not forcing the calculation. It is your fiduciary responsibility to ensure that data is as accurate as you can make it so don't store data that can be easily calculated and will always be accurate if calculated but may be out dated if stored.
When we create a data warehouse as many large companies do for reporting. The data warehouse is always AS OF some date and no individual records ever get changed. The complete set of data is replaced or updated every day, week, month - whatever but never in between. Given that, it is quite OK to store calculated values and doing so simplifies the user's work and minimizes the knowledge he needs to create custom reports.
