Re: large table strategy

>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); t>ransactions 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). I'm firmly of the opinion that if your application code and operations can handle it, you're far better off seperating "current/active" data from historical data. That's one of the reasons that we've seen the two terms DSS vrs OLTP be treated as opposites. The needs of OLTP is for very fast bursts of processing while DSS/historical data tends to be more "batch style processing". There are problems with designing for these two environments, but I'm still convinced that the best solution is to seperate them as much as possible. Madison Pruet