tags:

views:

195

answers:

4

Just wondering if anyone has ever thought of/implemented something like this.

I'm considering implementing a DB versioning scheme. Once per day, a job would run, which outputs all DDL and source code into a single file. A hash would then be run against that file. The hash would be stored in the DB with a version number. Anytime the hash changed, the hash value would be updated and the version number incremented.

Does that make sense? Anyone see any huge holes in that other than the fact it would happen once per day?

Anyone done something similar?

A: 

Another approach could be to script your incremental changes so that the sum of these scripts represents your current version. The advantage is that - especially if you are developing in a team - the individual scripts can be tested on a local instance before being committed to the repository.

I'd use a series of incremental scripts if the changes are many and frequent, and your approach if the database code has reached a certain level of stability.

davek
A: 

Not sure what you see as the use for this. I'd tend towards AUDIT and/or DDL triggers to capture code changes in the database.

I wouldn't use this in place of a proper source code control versioning, though it may be better than nothing if that doesn't exist and you are powerless to put it in place.

One thought is that sometimes reference data is as important as code.

Gary
A: 

Something along the lines of Workspace Manager although is for versioning data:

http://www.oracle.com/technology/products/database/workspace_manager/index.html

Stellios
+1  A: 

Here's a blog post by some random guy about the subject. He links to a few good articles to give ideas.

http://www.codinghorror.com/blog/archives/001050.html

Adam Hawkes