The capistrano approach is to collect a set of SQL sequences that will alter a sample server configuration from one configuration to another, with the purpose of repeating this on other servers such as your production server.
This is fine if you are paid by the hour.
The smarter way is to make changes that span codebase versions. You want to normalize a table so entities can have more than one address? Build an addresses table crosswalked to entity id and let the new code use it. Once you're happy with it you can drop some columns, but if you need to roll back, you haven't thrown anything away.
To me the difference is like that between hiring a hooker and charming a cheerleader. Either way you should make backups. ymmv.
Hmm, I don't think I understand the diference. Aren't you both in the capistrano case and the 'span codebase' example adding a table for example, so wouldn't both cases require repeating sql sequences?
Although maybe what you are saying is that you can make 'dumb' sql changes which break compatibility with past code vs 'smart' sql changes and code changes which are backwards compatible?
This is fine if you are paid by the hour.
The smarter way is to make changes that span codebase versions. You want to normalize a table so entities can have more than one address? Build an addresses table crosswalked to entity id and let the new code use it. Once you're happy with it you can drop some columns, but if you need to roll back, you haven't thrown anything away.
To me the difference is like that between hiring a hooker and charming a cheerleader. Either way you should make backups. ymmv.