| 290 | |
| 291 | Something Completely Different |
| 292 | ------------------------------ |
| 293 | |
| 294 | I'd like to suggest a different approach altogether. |
| 295 | This is, I think, orthoganol to the version management part of the existing proposals. |
| 296 | Call this the DatabaseRefactoring view of schema evolution. |
| 297 | For background, let me suggest a few starting points: |
| 298 | |
| 299 | * Fowler and Sadalage's paper `EvolutionaryDatabaseDesign`_ |
| 300 | * `TheProcessOfDatabaseRefactoring`_ from Scott Ambler's agiledata site, which leads to the online catalog of refactorings |
| 301 | * and of course there's Ambler and Sandalage's book, `RefactoringDatabases`_ |
| 302 | |
| 303 | I think there are several important advantages to this approach as compared to the one already suggested. |
| 304 | For one thing, the smaller steps it takes are likely to be much more automatable. |
| 305 | Sure, in some cases you'll have to write conversion code, but a lot of changes shouldn't require this. |
| 306 | If you're evolving your application by (in part) refactorings, then there's an obviously good match (object refactorings map to database refactorings). |
| 307 | |
| 308 | .. _EvolutionaryDatabaseDesign: http://www.martinfowler.com/articles/evodb.html |
| 309 | .. _TheProcessOfDatabaseRefactoring: http://www.agiledata.org/essays/databaseRefactoring.html |
| 310 | .. _RefactoringDatabases: http://www.bookpool.com/sm/0321293533 |