Re: [agileDatabases] keeping history
- thanks guys. I've read all u've written and they
helped me so much. I hope I will share my experience.
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
- On Wed, 18 Jul 2007, Gabriel Tanase wrote:
> If most of the SQL in your applications only deals with current data, thenNot at all. It's quite easy to keep it all in one table and create a
> keeping history in the same table(s) will force each and every SELECT to
> include at least a condition involving the "current indicator" column. To
> avoid clogging each and every SQL with conditions on the history management
> columns, it is therefore better - in this scenario - to keep history in
> separate tables.
view for the current data, and have all of your "current data" queries
work against that view.
The one-table design also simplifies setting up constraints.
Unfortunately, on larger tables (that grow to hundreds of thousands or
millions of rows) that become filled with mostly history, you may start
to run into problems with performance that can be fixed only by changing
your logical design, since in most DBMSes the logical and physical
designs are inextricably linked. But don't give in soon, other tricks,
such as the clustered index on the "current data or not" property one
mentioned earlier in this thread, can help.
Curt Sampson <cjs@...> +81 90 7737 2974
The power of accurate observation is commonly called cynicism
by those who have not got it. --George Bernard Shaw