Reputation: 23
Many applications accumulate binary dust -- records that were accumulated over time and will never see the light of day. Our application keeps a chat history, and only displays the last 5 days worth of such records. Is it a good idea to run a cleanup operation after a while that moves those old records to a 'history' table. The history table will never be used, but just allows us to run internal statistics, whilst (I assume) enabling better performance on those records remaining in the main table.
Also, if we do build a history table then do we need to replicate our tables, or is there a hidden MS SQL function that will create "shadow tables" automatically.
Upvotes: 2
Views: 172
Reputation: 3218
cyberkiwi is correct regarding "no magic" and his recommendation is fine for simple data. When the data is complex, the archiving becomes complex. You may find that you want to denormalize data when archiving, so that you can then delete or modify the data that the original rows referenced.
Upvotes: 1
Reputation: 107776
There is no MS SQL function that will create such shadow tables automagically. It comes close with partitioning, but that really splits the storage (fast/slow) while still keeping data in one table.
What you are looking for is a straight archive and purge. A simple strategy is a nightly task to
date < getdate()-6
to history tableIf this table has foreign key links to
other tables, you will find it unlikely that those tables need to be purged unless they too grow quickly (rare). If other tables have FKs to the primary on the other hand, that is a different matter. In that case, you would have to move all the dependent children, then the primary, then finally delete in reverse order.
Upvotes: 1