Muchas personas intentan hacer este tipo de cosas (esquemas diferenciales). Mi opinión es
- El código fuente entra en una herramienta de control de versiones (Subversion, CSV, GIT, Perforce...). Trátelo como si fuera código Java o C, realmente no es diferente. Debe tener un proceso de instalación que lo verifique y lo aplique a la base de datos.
- DDL ES EL CÓDIGO FUENTE. También entra en la herramienta de control de versiones.
- Los datos son un área gris:las tablas de búsqueda tal vez deberían estar en una herramienta de control de versiones. Los datos generados por la aplicación ciertamente no deberían.
La forma en que hago las cosas en estos días es crear scripts de migración similares a las migraciones de Ruby on Rails. Coloque su DDL en scripts y ejecútelos para mover la base de datos entre versiones. Agrupe los cambios de una versión en un único archivo o conjunto de archivos. Entonces tiene un script que mueve su aplicación de la versión x a la versión y.
Una cosa que nunca más hago (y solía hacerlo hasta que aprendí mejor) es usar cualquier herramienta GUI para crear objetos de base de datos en mi entorno de desarrollo. Escriba los scripts DDL desde el día 1; los necesitará de todos modos para promocionar el código para prueba, producción, etc. scripts para crear/migrar el esquema correctamente que a menudo no se prueban y fallan!
Todos tendrán sus propias preferencias sobre cómo hacer esto, pero he visto muchas cosas mal hechas a lo largo de los años, lo que formó mis opiniones anteriores.
