One of the best resources I have found for database development was by Scott Ambler, “Agile Database Techniques.” The primary reason I say that is not to espouse the Agile Software Development Lifecycle as much as to encourage many incremental improvements.
One of the things the Japanese auto makers started was a different way to introduce new features in their vehicles. Instead of having major model changes every few years, they released incremental improvements every year. This meant the re-tooling necessary to build their vehicles didn’t need to be replaced in whole. They could focus on specific areas and bring them to excellence. They could bring newer technologies to the market more quickly because they didn’t need to wait for a long cycle of development to complete.
This same mind set works extremely well in database systems. Any DBA can tell you that it is a lot easier and more reliable to make a few small changes to a database than to make many large changes all at once. How big the definition of small or large changesare depends on the pieces being changed, and the dependency of the changes to one another.
For example, adding a column to a table may not be a big change. However, if you are changing a number of stored procedures to take advantage of that new column, the migration of those changes becomes more complicated. The more changes and dependencies added, the more complicated the change becomes.
Using Agile techniques for database development makes it easier to create the migrations in smaller increments. You know you want to move your database from A to Z. However, you don’t have to get there in a single release. You can do smaller increments. Move from A to B. From B to C. Ultimately, you’ll get to Z, and with a much more stable migration. Don’t force yourself to do everything at once. Be comfortable with having legacy implementations still working. You may even have a legacy feature working along side of something intended to replace it for a period of time.
This doesn’t mean you have to release the whole thing in tiny increments. Your migrations should be able to be packaged together allowing you to release your database changes in a meaningful manner working together with other tools and processes.
Think Small To Make Big Changes
Cheers,
Ben