Best practice for managing data-model changes in a released system

Question

I am about to embark on the development of a web application project.

I'd like to get something up early and often for early adopters to play with and feedback.

But I envisage the data model changing as the project progresses and my understanding of the system improves.

How should I manage the dilemma of updating the data model appropriately and preventing data loss for early adopters? Should I simply put up a big warning saying "user beware", or should I put in the effort to create migration scripts?

Answer 1

Scott Ambler has written some nice stuff about agile databases. There's a book and a website.

Answer 2

The first time I ever heard about agile data was a talk by Martin Fowler and Pramod Sadalage.

Answer 3

What platform are you using? Ruby on Rails gives you migration scripts as part of the package. If you're in Java-land, you might want to check out migrate4j.

In the end, I'd suggest doing both things: Warn your users that they're using alpha software, and employ migration scripts with the intent of preserving their data whenever you can (lest they become peeved and lose interest).

Answer 4

@bradheintz; I'm using the Microsoft Web Stack.

I have found a short list of .NET related migration tools here:

http://flux88.com/blog/net-database-migration-tool-roundup/.

Answer 5

For my company ...

It's a hard and fast rule that, when possible, the database MUST be backwards compatible with the current version of the software. If it's not resort to tar and feathering tactics against the offender.

In our case, we write custom software application for our customers, so we have some flexibility on how we can implement things ... but more often or not, the customer wants to view their changes with live data. So we have to be able to support the current version of the application, plus the new version of the application that customer is reviewing and approves.

Some other things we do is invested in Red Gate's Sql Compare and Sql Data Compare. This make sure changes from the development environment get moved into the production environment correctly.

We also have recently abandoned the use of stored procedures, as they provide an unnescessary layer of abstraction when it comes to maintenance ... and they are evil! =)