Question

I have a table that contains some statistic data which is collected per hour.
Now I want to be able to quickly get statitics per day / week / month / year / total.
What is the best way to do so performance wise? Creating views? Functions? Stored procedures? Or normal tables where i have to write to simultaneously when updating data? (I would like to avoid the latter).
My current idea would be to create a view_day which sums up the hours, then a view_week and view_month and view_year which sum up data from view_day, and view_total which sums up view_year. Is it good or bad?

Answer 1

You essentially have two systems here: One that collects data and one that reports on that data.

Running reports against your frequently-updated, transactional tables will likely result in read-locks that block writes from completing as quickly as they can and therefore possibly degrade performance.

It is generally HIGHLY advisable to run periodic “gathering” task that gathers information from your (probably highly normalized) transactional tables and stuff that data into denormalized reporting tables forming a “data wharehouse”. You then point your reporting engine / tools at the denormalized “data wharehouse” which can be queried against without impacting the live transactional database.

This gathering task should only run as often as your reports need to be “accurate”. If you can get away with once a day, great. If you need to do this once an hour or more, then go ahead, but monitor the performance impact on your writing tasks when you do.

Remember, if the performance of your transactional system is important (and it generally is), avoid running reports against it at all costs.