large table strategy

I'm developing an On-Line data base that has to handle about 150,000 transactions/day (25MBytes/day of data) that needs to remain on line for one year. Conceptually one huge table. But to make retrieval efficient (and archives manageable) I'm considering breaking that up into three tables: transactions over the last 24 hours (often queried, response has to be fast); transactions over the last 63 days (to enclude all current billing cycles, queried less often, but response still has to be fairly reasonable); and previous month's transactions (not often queried, response need not be rapid). Sensible? Or are there better approaches? This must be a fairly common situation. Surely some other folks have faced essentially the same problem before...