SQL - Source Control and Schema/Script management

Question

My company has just gone though its annual review process, and I have finally convinced them that it is time to find a better solution to manage our SQL schema/scripts. Cur

Answer 1

I'm in the "script it yourself" camp, as third-party products will only get you so far at managing database code. I don't have one script per object, because objects change over time, and nine times out of ten merely updating my "create table" script to have three new columns would be inadequate.

Creating databases is, by and large, trivial. Set up a bunch of CREATE scripts, order them properly (create database before schemas, schemas before tables, tables before procedures, called procedures before calling procedures, etc), and your done. Managing database change is not nearly as simple:

• If you add a column to a table, you can't just drop the table and create it with the new column, because doing so would wipe out all your valuable Production data.
• If Fred adds a column to table XYZ and Mary adds a different column to table XYZ, which column gets added first? Yes, order of columns in tables doesn't matter [because you never use SELECT *, right?] unless you're trying to manage the database and keep track of versioning, at which point having two "valid" databases that don't look like each other becomes a real headache. We use SQL compare not to manage but to review and keep track of things, particularly during development, and the few "these are different (but it doesn't magger)" situations we have can actively prevent us from noticing the differences that do matter.
• Similarly, when when multiple projects (developers) are working simultaneously and separately on a shared database, it can get very tricky. Perhaps everyone's working on the Next Big Thing project, when suddenly someone has to start work on bug fixes on the Last Big Thing project. How do you manage the required code modifications when the order of release is variable and flexible? (Fun times indeed.)
• Changing table structures means changing data, and that can become hellishly complex when you have to deal with backwards compatibility. You add an "DeltaFactor" column, ok, so what do you do to populate this esoteric value for all your existing (read: legacy) data? You add a new lookup table and related column, but how do you populate it for existing rows? Such situations may not happen often, but when they do, you have to do it yourself. Third-party tools simply cannot anticipate your business logic needs.

Essentially, what I have is a CREATE script for each database, followed by a series of ALTER scripts as our code base changes over time. Every script checks whether or not it can be run: is this the right "kind" of database, have the necessary prerequisite scripts been run, has this script already been run. Only when the checks are passed will the script perform its changes.

Tool-wise, we use SourceGear Fortress for basic source control, Redgate SQL Compare for general support and trouble-shooting, and a number of home-grown scripts based on SQLCMD for "bulk" deployment of the alter scripts to multiple servers and databases and to track who applied what scripts to which databases at what time. End result: all our databases are consistant and stable, and we can readly prove what version any one is or was at any point in time.