> Exactly. There are two almost identical schemas, one for current data and one > for the history.
This is not guaranteed to help performance. Growing table sizes tend to degrade performance because the data is spread over a larger disk area, but if history and live data are created incrementally, the tables will be interleaved on disk. Unless the DB engine goes to extra lengths to keep the data of each table in one area of the disk. However, if you put both live and history data into the same table and distinguish them via a flag, most DB engines support partitioning, which could help combat the spreading effect. This all is highly dependent on the engine and its configuration, so you really need to check what optimization tweaks are possible. But don't split into tables just for optimization... Unless you're on Mysql, where I once was really forced to split stuff because the optimizer was incapable of query rewriting. That's a few years old, though, so I don't know what today's Mysql optimizer can or cannot do.
