¿Cómo versiona / rastrea los cambios en las tablas SQL?

Cuando trabajas en un equipo de desarrolladores, donde todos están haciendo cambios en las tablas locales y las tablas de desarrollo, ¿cómo mantienes todos los cambios sincronizados? ¿Un archivo de registro central donde todos guardan sus cambios sql? ¿Una página wiki para rastrear las declaraciones de la tabla alter, archivos individuales .sql que los desarrolladores pueden ejecutar para llevar sus bases de datos locales a la última versión? He usado algunas de estas soluciones, y estoy tratando de obtener una buena solución sólida que funcione, así que agradecería sus ideas.

Utilizo una herramienta de migración de base de datos basada en código y mantengo el código de migración en control de origen.

Mediante el uso de marcas de tiempo como números de versión, cualquier cantidad de desarrolladores son en su mayoría libres de agregar migraciones a su antojo y podemos ejecutar la herramienta de migración contra cualquier copia de nuestra base de datos con confianza.

Solía ​​usar SQL Scripts bajo control de versiones, pero encuentro el enfoque basado en código mucho más fácil de trabajar debido a que todos están en un "punto" lógico y son capaces de ejecutar todos los scripts necesarios con un solo comando.

No lo hago yo mismo, pero algunos desarrolladores mantienen una colección de scripts SQL bajo control de origen que, cuando se ejecutan, pueden recrear las tablas de la base de datos con fines de prueba y construir una base de datos vacía para fines de producción.

Se puede usar la misma técnica para versionar la base de datos en el sitio del cliente, cuando se deben agregar o eliminar campos o tablas, o se deben realizar transformaciones de datos.

Cree scripts bajo control de versiones e integración continua para verificarlos

Un enfoque que funcionó para mí fue que cada desarrollador trabajara con su propio esquema, con el que pueden hacer lo que quieran. Su esquema era destructible y estaba lleno de datos de prueba tomados de un conjunto de scripts controlados por versiones a los que contribuían todos los desarrolladores.

La compilación de integración continua nocturna tomó la última versión de todos los scripts e intentó construir una base de datos de prueba coherente a partir de ellos. Luego, la aplicación realizó una serie de pruebas integrales y funcionales para verificar que el esquema actual estuviera en línea con el candidato de versión actual.

Antes de comenzar este camino, había un diseño de base de datos bastante sólido y un DBA siempre estaba atento a las cosas para evitar que los desarrolladores se volvieran locos con la desnormalización y otros horrores.

El control de versiones ayudó enormemente aquí porque los cambios en los scripts fueron inmediatamente obvios. También hicimos uso de una VERSIONtabla de base de datos para identificar el estado general de la base de datos. Esta era una secuencia entera simple y no estaba vinculada a ninguna aplicación en particular.

En general, funcionó bien y significó que los desarrolladores dejaron de temer cambiar los niveles de persistencia porque siempre podían revertir sus propios esquemas sin afectar a los demás.

Si está en una tienda de MS, Visual Studio 2010 tiene algunas buenas herramientas de control de versión de base de datos, que también pueden generar scripts de cambio / implementación basados ​​en las diferencias entre dos bases de datos.

Además de mantener los esquemas y otras secuencias de comandos SQL bajo control de versión, otra práctica útil es mantener una tabla de 'versión de esquema' en la base de datos real .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrine tiene una increíble herramienta de migración: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , la mejor parte es que son autogenerados o pueden codificarse fácilmente a mano.

El enfoque que uso es proporcionar una tabla para los parámetros. Esta tabla tendrá un par de nombre / valor para la versión en la que se encuentra la base de datos. Esto me da dos beneficios: tengo una manera de verificar que una base de datos solo se ha aplicado a través de la aplicación, y puedo usar ese valor para mis scripts SQL.

El script SQL creará nuevas tablas, alterará las columnas y cualquier trabajo que se necesite en la base de datos para promover el script desde la versión anterior. Idealmente, también tendría un script de reversión, pero la mayoría de las veces no.

Por cierto, todo este enfoque se ha automatizado como parte de Ruby on Rails, completo con los scripts de reversión. Me gusta la idea de eso, pero no todos los marcos lo hacen. Cuando no estoy usando Ruby on Rails, uso el enfoque descrito anteriormente.