Large Table management

Hi netters, Currently, our production data is growing at a rate of 25,000 rows/month to 25,000/day. Thses cause the table to grow very large. Is there a standard practice on how to handle such large table? These data may be used for yearly or monthly report. At the production environment, performance is critical. What I did to these table was to make the table as small as possible (eg keep a week's info) and daily backup the data to another table by Cron. The backup table grows while the production table is static. Do you think this is a good way of data management? How about spliting up backup tables into monthly data so that it is easy for me to know the data collected for that particular month. Will the performance of generating reports from this tables be greatly affected? Of course there are some raw data that can be summarized into daily/ weekly/monthly which greatly reduce the number of rows stored. However, there some raw data that can't be summarized. I'm talking about the latter. Please share with me your current ways of handling large tables such that it is easily accessible without performance being greatly affected. Thanks. Cheers, Cynthia Leong Hewlett-Packard, Singapore cynthia@hpsgcip1.sgp.hp.com