keeping sql database schemas synced between developers

Question

We are a small development team (about 5) doing a dev project from different locations. We use SVN as out code repo.
The biggest issue that we are having now is that our DB schema is totally out of sync between all of us. I have though of the following options: 1. Work off a "central" DB. This is a bad idea and will most likely not happen 2. Have a "gatekeeper" developer that will keep on version of the DB and have each developer keep them up to date with the changes. 3. Make each developer check their changes into a DB change script. This can get messy really quickly.

Sorry just to mention that it is a .net c# project

Any ideas?

Answer 1

Have you considered using the Visual Studio Team Database Edition? It lets you put your whole source database into source control, and each developer can work on their own changes, and then once they check them in, the other dev's can easily deploy those changes to their own working copy.

Not sure if there's an SVN plugin that would work with the MSSCCI provider - but I imagine that there should be something out there for that.

Answer 2

Assuming you aren't using the Team Edition visual studio products, then I'd pick option 3. Have the sql script under source control as well.

Keeping their local databases in sync is no different than requiring them to work with the latest source code.

If you are using the Team products, then start using the Database edition (comes with Developer Edition) to manage your database under source control

Answer 3

This is a difficult problem. We dealt with it by revisioning the sql used to generate the schema (auto-generated from Enterprise Architect). We had huge problems where people would not update their database schemas because they felt it took too long to re-create a dataset that had valid testing data.

Our solution was to:

• Add SQL Schema Generation to SVN
• Add Data Insertion Scripts to SVN
• Add Schema/Data dumps to SVN

We used Hudson to setup an automated database build that would check for changes in the revision. It would automatically re-create the schema, insert all the data, export a dump file, and then commit the dump file to SVN.

Basically, it boiled down to running a database import which took about 20 seconds. Once you make the database creation fast, then developers won't have a problem doing it frequently.

Answer 4

I work on a small team as well, and right now we have our SQL schema and data insertion scripts checked into a repository just like our code.

You'll need to make sure people are keeping up to date with the latest "source". We tend to make it practice that for any major changes/revisions that we meet up and discuss them anyway, to keep everyone informed as to what's being modified as well as offer a chance to review any database updates before they are put out.

Answer 5

This problem doesn't get any more common. Every team has to ask this question at some point. I've done the common DB approach and the separate DB approach. The team has always gone back to the common DB. It's just easier to maintain and everyone should be syncing early, syncing often. This does not negate the need to keep schema changes and definitions in version control though. You need a repeatable process to updating your test, staging and production environments. Pure SQL migrations are not always sufficient though, there will be times where you need to use your native objects to generate the data or make decisions. The best system I've seen (resembles systems I've built myself in perl, php and Java, but improves on a couple of points) is the Ruby on Rails migration system. Check it out and do something similar.

Answer 6

Why would working off the same database server be a bad idea again? Because all the developers are making changes that could hurt others? If that's the case, I'd have one person deal with schema changes and use VPN to get in to the network that has the database server. I'm in this same boat right now, just picked up a Cisco router to deal with my VPN needs for cheap (< $100).

Answer 7

I read an artile a few years back from Paul Graham, about "Agile Database Development". I'm having trouble googling it though. It seems all of those terms are a bit too generic, and my memory is a bit too fuzzy to get closer.

I did run acrossed http://code.google.com/p/migratordotnet/

It's modelled on the Rails ActiveRecord migrator (mentioned earlier), but aimed at .net. I'm not a .net programmer, but it sounds like the sort of thing you're looking for.

Answer 8

There's a third party tool, just for that - Randolph (SQL Version control)

Answer 9

We had the same problem in the project I'm currently working in. We've adopted Tarantino as a solution which works surprisingly well. Each developer is working against a local database. When a developer needs to make a schema change, he/she creates a script and checks it in.

Tarantino keeps track of which scripts each developer has already run on their local database and applies the new scripts. So if developer A makes a change and checks in the SQL script, developer B will get the change when he/she gets the lates files from source control. When developer B runs Tarantino locally only the latest scripts will be applied.

Granted, most of this can be done manually. Tarantino makes it easier but it is not perfect. One advantage is that it can be integrated into the build process fairly easily. Scripts for maintaining the data in the databases can also be created.

Answer 10

MS is a little behind in that it doesn't have a standard solution to this yet, but your #3 option (change scripts) is the way to go nowadays. Most other modern mainstream languages use a form of this nowadays in various different flavors. e.g. Check out Rails migrations.

This post discusses a bunch of 3rd party .NET solutions are available. In my experience, migratordotnet is an excellent choice. For a more detailed examination of the problem, check out Martin Fowler's article on the subject.