I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations
On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear <stu...@skproactive.com>wrote: > I guess this is an age old problem, managing database changes such that > they respect applications dependent on them. We are bolting more > applications to a couple of sql databases so the management exercise is > becoming more complex, risky and expensive to maintain. > > Currently we have a database version number, use schema naming for > application specific views and procedures and have a folder of each change > in sequential order that has to be applied to production. > > Over the holiday break I thought I might research how we can improve our > approach. What systems have you or your organisations adopted to keep it > all under control , and are they successful? > > > -- > > ----------------------------------------------------------------------------- > Stuart Kinnear > Mobile: 040 704 5686. Office: 03 9589 6502 > > SK Pro-Active! Pty Ltd > acn. 81 072 778 262 > PO Box 6117 Cromer, Vic 3193. Australia > > Business software developers. > SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. > > ----------------------------------------------------------------------------- > >
