Why isn't database version control considered as important as application version control?

Question

I've recently started using Kiln Source Control for all my projects VB.NET code, and I don't know how I managed without it!

I've been looking for a database source control, for all my stored procedures, UDFs etc. However, I've found that there is not as much available for database version control as there is for my web files.

Why is database version control not considered as important as my web files? Surely all the programming in my database is just as important as the code in my code-behind and .aspx files?

Answer 1

Version controlling database objects IS important!

However, maybe it isn't considered as important because some people see a database merely as a tool that assists them? And external tools (normally) aren't version controlled.

One thing I've found hard to manage is the release process. Right now we're using red gates source control connected to svn. When it's time for release we do the same as with the rest of the code: Merge from one branch to the other. Then to deploy it we use sql compare to create a diff script between the merged revision and the actual database. Aside from some minor quirks and beginners mistakes I think this works well in a environment where there is no downtime (purposefully ;)) and which has a high speed development process (lots of releases).

Answer 2

You can maintain your database artifacts in your version control system for same. Version control system is for versioning of artifacts and Artifacts can be Program code or database. We used same VC for code and database.

Answer 3

I don't know if or why it's not considered as important, but here's a link to something that might help:

http://code.google.com/p/migratordotnet/

Answer 4

VCS are designed to store versions of text. They can store binaries but it is less efficient. And the DB state itself is not a text and can't even be directly stored as a binary. You can store the SQL code though.

one solution is to store a full DB dump (SQL or binary), another - to store sequences of SQL scripts that change one DB state to the next one. The second approach can be automated in some environments and is there called migrations. if you want a separate specific VCS for a DB, you can think that migration tools are such VCS.

There are also tools that can compare two DB states and produce a diff that is able to change the first state to the second.