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 don't think there is a tool that can handle all the pieces. VS Database Edition falls short of offering a decent release mechanism. Running individual scripts from the solution explorer does not scale well in larger projects.

At a minimum you need

• an IDE/editor
• a source code repository that can be ingrated with your IDE
• a convention for naming and organizing your various scripts into folders
• a process for handling changes, managing releases, and doing deployments

The last bullet is where things usually break down. Here is why. For better managability and version tracking, you want to keep each db object into its own script file. I.e. each table, stored procedure, view, index, etc has its own file.

When something changes, you update the file, and you have a new version in your repository with the information that you need. When it comes to bundling a number of changes into a release, dealing with individual files can be cumbersome.

2 options that I have used:

• In addition to keeping all the individual database objects in their files, you have release scripts that are a concatenation of the individual scripts. The downside of this: you have code in 2 places, with all the risks and disadvantages. The upside: running a release is as simple as executing a single script.

• write a little tool that can read script metadata from a release manifest and execute eadch script that is listed in the manifest on the target server. There is no downside to this, except that you have to write code. This approach does not work for tables that can't be dropped and recreated (once you are live and have data), so for tables you will have change scripts anyways. So in reality, this will be combination of both approaches.