Performing database versioning the hard way means going into some management software and manually making changes to fields, tables, and relationships. This works fine for a one person project. But as soon as more developers are added to a project making use of one or more databases, chaos is bound to ensue.
Many shops have learned the wisdom of using version control to ensure consistency and centralization of source code control. On the other hand, very few have been able to do database versioning in a like fashion.
Mooney has a different way of saying it, but I suppose it boils down to:
- software versioning is reasonably easy as it only relies on getting everyone's text to play well together, and is usually processed in batches, but is otherwise in a quiescent state
- database versioning is more difficult as there are at least two factors at work: a) the database schema, which defines the data, and b) the data itself, with both living in a dynamic, always-on environment
Versioning your development databases has another good overview of handling versioning, testing, and deployment of database changes. All handled in a fashion similar to normal code version management.
The most elegant solution I've seen to-date is found in the Python language environment, specifically the SqlAlchemy database library through the Alembic add-on.
And to prove that this is not a new problem, there is a book called "Refactoring Databases: Evolutionary Database Design" which has been out since 2006.