Re: large table strategy

Bob Cunningham wrote: > > 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... Hi, if you are running OnLine 7.x, how about fragmenting your table by an expression ? I guess this will be easier for the programmers when you want to retrieve rows from the whole table. Then we would talk about "One table, but several fragments ". Bye Stefan