Comments on: Episode 186: Martin Fowler and Pramod Sadalage on Agile Database Development

By: Database Refactoring « 36 Chambers – The Legendary Journeys: Execution to the max!

Fri, 14 Sep 2012 22:06:36 +0000

[...] In contrast is Martin Fowler and Pramod Sadalage on database refactoring and development. [...]

By: SE Radio podcast with Pramod on Agile Database Development | Jisku.com - Developers Network

Wed, 05 Sep 2012 18:13:31 +0000

[...] Source Article from http://www.se-radio.net/2012/06/episode-186-martin-fowler-and-pramod-sadalage-on-agile-database-deve… [...]

By: Artie

Artie — Mon, 18 Jun 2012 21:42:42 +0000

What strategies are people using to handle branches? In the past, we’ve come up with namespaces for sets of scripts and all we had to do was make sure that the namespaces were executed in the correct order. I know that rails uses timestamps now. Have people tried anything else that worked?

By: ross

ross — Mon, 18 Jun 2012 02:23:15 +0000

Good episode.

However, I’d be surprised to work on a project that didn’t roughly use the proposed approaches. Every project I have worked on for 10+ years has used similar techniques.

By: Chris

Chris — Thu, 14 Jun 2012 19:30:30 +0000

I’m going to have to agree with Steen on this one, best episode ever.

By: Fábio Franco Uechi

Fábio Franco Uechi — Wed, 06 Jun 2012 18:53:37 +0000

I’ve experienced both worlds and undoubtedly, the best way to approach database evolution incrementally is by using the cited techniques.
Unfortunately I’ve seen companies demanding the delivery of Erwin files (or another database maintanance tool) which in most of ocasions cannot be automatically generated based on the migrations/patches.
These situations might generate extra efforts if we fail to convince the customer that keeping database under version control is a much better way of working.

By: Hal Arnold

Hal Arnold — Wed, 06 Jun 2012 04:14:17 +0000

Nice beginning article.
I was hoping for a description of how one would migrate or modify the production application’s database when that application has continuous transactions.
We’d like to complete a continuous delivery environment, all the way to actual production release. But we haven’t been able to figure out how to roll back migration or mod changes to the db because in the time that the modified scripts are ‘out there’ there, even for a short time, there can be literally thousands of writes and writes based on the changing db.
We’ve thought about having a parallel schema, and keeping both up, where we queue up all the changes, so that we could roll back and then run the changes to the ‘rolled back to’ old schema, but haven’t had the courage to try.
Any ideas on this score?

By: Software Engineering Radio « Dinkar's Thoughts, Ideas and Experiences

Software Engineering Radio « Dinkar's Thoughts, Ideas and Experiences — Tue, 05 Jun 2012 05:55:46 +0000

[...] Agile Database Development [...]

By: Michael Pollmeier

Michael Pollmeier — Mon, 04 Jun 2012 02:05:57 +0000

Solid episode, well done! I believe – and you sort of mentioned it – that the crucial point is the undo path, i.e. if you want to migrate back to an older version. With these tools (I used dbdeploy) you need to write your undo scripts manually and as database constraints might only catch you once the data has moved forward.
I guess the only way to make sure you haven’t screwed up the scripts is to set up your continuous integration server to downgrade to a far earlier version and make sure that still works..

By: Steen Hutlhin Rasmussen

Steen Hutlhin Rasmussen — Sat, 02 Jun 2012 11:28:07 +0000

Maybe the best episode since the software archeology episode – maybe even best ever.

I would like to add a link to a good read to getting started with some of the most basic techniques mentioned in the podcast. In a series of posts K. Scott Allan describes some basic versioning practices: http://odetocode.com/Blogs/scott/archive/2008/01/31/three-rules-for-database-work.aspx
A very good read for the beginner on this topic.