Database structure and source control - best practice

Question

Background

I came from several years working in a company where all the database objects were stored in source control, one file per object. We had

Answer 1

We have all our database objects under source control using Visual Studio Database Edition (DBPro). It is a wonderful tool that version controls our schema, does builds, validations, allows code analysis, schema comparisons, deployments, data comparisons, refactoring etc. It was designed from the ground up to be a DB management and version control system. Highly recommended.

This is the blog site of the lead architect for DBPro: click here

Answer 2

Have a look at this five part series on the principles and practices of database version control (by K. Scott Allen):

1. Three rules for database work
2. The Baseline
3. Change Scripts
4. Views, Stored Procedures and the Like
5. Branching and Merging

The five parts are important but basically the idea is to have a baseline and then change scripts (with a version table). Updating the database means applying change scripts "above" the current version. And this strategy is very VCS friendly (no conflicts).

Answer 3

I am not very familiar with RedGate toolkit, but if it is any similar to dbGhost, there must be a utility that allows you to script the database objects to the files one per object. In this case I would suggest following:

• add a daily (or part of a build) job to reverse-engineer the DEV database into the directory structure
• then compare it to what you have in repository (by means of simple diff), and basically FAIL the build job and report the diff if any. This will indicate that the structure of the DEV database has changed and is not reflected in the source control,
• which will indicate to the developer to add the changes to the source control (even use the reported .diff file for this)

If you many DEV databases (one per user or development branch) and it is too cumbersome, then probably a better combination would be to do such task on the STAGE (TEST just before release) version of the database, at which point you would store the PROD schema in the repository and would update it from the STAGE only during the pre-release testing phase, where you will ensure that your schema changes are also in the repository.

This way developers can still work in the usual way: change the schema on the DEV database first, and hopefully you get the balance between the flexibility and one truth you would like.

In my team we add change to VCS as soon as we change the DEV database, but we still do have such task to compare the schema between different databases (DEV, STAGE and PROD). Basically, we follow what I once answered in How should you build your database from source control?.

Answer 4

If you're already using Red Gate tools, you might consider using SQL Source Control, which works side by side with SQL Compare and SQL Data Compare to allow one version of the truth to exist in source control. It's in early access at the moment, but most of the functionality is in there to be tried out. You can download this from http://www.red-gate.com/Products/SQL_Source_Control/index.htm . However, it only supports SVN and TFS for the moment. Have you standardized on GIT?

David (Product Manager at Red Gate)