First, let me point out that I read all the posts regarding database versioning, but this isn’t exactly the thing I’m looking for, but I couldn’t come up with a better title (the word ‘full’ here is the key).
I have a ‘compiled database’, that holds all kind of optimization records and statistics for a public transportation route planner, and it’s generated through a program from another database. The compiled database never changes while it’s active, except for user activity monitoring and caching. Some tables contain as much as 2-300,000 records.
This compiled database is fully renewed once a change occurs in the input database. So, any new database version doesn’t interact with any other previous version, in any way. But I would like to store each version separately, and have the opportunity to use it from the program if the user desires (think of it like a history of public transportation maps).
The only reasonable method is simply to make different physical databases for each version, which is neither hard nor wrong, but I’m asking if you know any mechanism for versioning full databases (not just parts of data inside it, like the other posts are asking), for the purpose of making the whole thing more logical and clean.
I’m using SQL Server 2012, but probably on the server it will be 2008 R2.
And if you think of storing versioned data in the same database (and add a VersionID column in each table) forget about it, because on a table with 2-300,000 records, 10 versions (which would accumulate in a period of less than 3 months) would mean more than 3 million records, from which only 300,000 would be used, so, no way!
I think the multi-database approach is good. You could try to do storage-level data deduplication. That would probably cut down storage usage considerable. Just make sure that you create the new database as a backup and restore from the old one so that they are mostly byte-identical.