Search code examples
databasesvnversion-controlchange-management

Database source control vs. schema change scripts


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.


Solution

  • Similar Questions

    One or more of these existing questions might be helpful:

    Or a search for Database Change