| | 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 |