Database source control vs. schema change scripts

Question

Building and maintaining a database that is then deplyed/developed further by many devs is something that goes on in software development all the time. We create a build script, and maintain further update scripts that get applied as the database grows over time. There are many ways to manage this, from manual updates to console apps/build scripts that help automate these processes.

Has anyone who has built/managed these processes moved over to a Source Control solution for database schema management? If so, what have they found the best solution to be? Are there any pitfalls that should be avoided?

Red Gate seems to be a big player in the MSSQL world and their DB source control looks very interesting: http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

Although it does not look like it replaces the (default) data* management process, so it only replaces half the change management process from my pov.

(when I'm talking about data, I mean lookup values and that sort of thing, data that needs to be deployed by default or in a DR scenario)

We work in a .Net/MSSQL environment, but I'm sure the premise is the same across all languages.

Answer 1

Similar Questions

One or more of these existing questions might be helpful:

• The best way to manage database changes
• MySQL database change tracking
• SQL Server database change workflow best practices
• Verify database changes (version-control)
• Transferring changes from a dev DB to a production DB
• tracking changes made in database structure

Or a search for Database Change

Answer 2

I look after a data warehouse developed in-house by the bank where I work. This requires constant updating, and we have a team of 2-4 devs working on it.

We are fortunate because there is only the one instance of our "product", so we do not have to cater for deploying to multiple instances which may be at different versions.

We keep a creation script file for each object (table, view, index, stored procedure, trigger) in the database.

We avoid the use of ALTER TABLE whenever possible, preferring to rename a table, create the new one and migrate the data over. This means that we don't have to look through a history of ALTER scripts - we can always see the up to date version of every table by looking at its create script. The migration is performed by a separate migration script - this can be partly auto-generated.

Each time we do a release, we have a script which runs the create scripts / migration scripts in the appropriate order.

FYI: We use Visual SourceSafe (yuck!) for source code control.

Answer 3

I've been looking for a SQL Server source control tool - and came across a lot of premium versions that do the job - using SQL Server Management Studio as a plugin.

LiquiBase is a free one but i never quite got it working for my needs.

There is another free product out there though that works stand along from SSMS and scripts out objects and data to flat file.

These objects can then be pumped into a new SQL Server instance which will then re-create the database objects.

See gitSQL

Answer 4

Maybe you're asking for LiquiBase?