Cuando realiza cambios en la base de datos, ¿cómo aplica estos cambios a otras bases de datos en el equipo (y también a sus servidores)?¿Cómo compartes los cambios de SQL dentro de tu equipo?
Actualmente estamos utilizando un archivo llamado changes.sql donde ponemos todos nuestros cambios, separados con comentarios de fecha ISO.
¿Hay una manera mejor?
Utilizamos una versión ampliada de su enfoque.
Tenemos una carpeta de actualización de base de datos para cada versión, que contiene todos los scripts que forman parte de la versión. Hay un archivo de índice en la carpeta, que contiene pseudo enlaces a todos los scripts que deben ejecutarse.
Tenemos un trabajo de control de crucero que se ejecuta todas las noches para restaurar una copia de la base de datos de producción actual y luego ejecuta los scripts de actualización de la versión actual (ejecutando los scripts definidos en el archivo de índice). También hay un trabajo de CI que se ejecuta cada vez que alguien revisa algo en la carpeta de actualización para la versión actual.
Los scripts deben poder volver a ejecutarse obviamente, por ejemplo, deben verificar la existencia de algo antes de soltarlo o crearlo.
Eche un vistazo a http://dbmaintain.org/overview.html - Es una herramienta bastante poderosa para administrar las actualizaciones de la base de datos. Básicamente funciona ejecutando varios scripts SQL en el orden correcto. Recuerda qué scripts ya se han ejecutado. Si se modifica un script ejecutado, informa un error (en modo de producción) o borra la base de datos y ejecuta todos los scripts nuevamente (en modo de prueba). También hay un buen tutorial.
Editar: También puede agrupar las secuencias de comandos sql (es decir, mediante versión). La gran ventaja aquí es que puede usar las mismas pruebas para las pruebas de su unidad, los entornos de prueba, la integración continua, los entornos casi en vivo y de producción.
No en mi trabajo actual, pero en el pasado usé un database project en Visual Studio 2010, que luego se publicó en SVN. Tuvimos un SOP en lugar de automatización de software para impulsar los cambios desde el desarrollo hasta el control de calidad, la puesta en escena y la producción.
El equipo con el que trabajé era pequeño: cinco desarrolladores con responsabilidad compartida para el diseño de DB y el desarrollo .NET.
También debería considerar el uso de control de versiones en su base de datos. Un ejemplo es Liquibase. Al usar el control de versiones, puede comentar todos los cambios en la estructura de la tabla, por lo tanto, no necesita un archivo changes.sql.
Utilizamos una herramienta de migración (migratordotnet - existen otras alternativas) que le permite escribir clases de C# que ejecutan comandos de base de datos. Las migraciones se ejecutan localmente en cada invocación del programa o de las pruebas de integración, y en los servidores de cada implementación. El marco de migración realiza un seguimiento automático de las migraciones que se han aplicado. Por supuesto, las migraciones son parte del repositorio de control de versiones.
Entonces, si el archivo de cambio contiene e INSERT INTO, ¿primero verifica su existencia? SELECCIONAR ... ¿DÓNDE? ¿Qué pasa si no hay un identificador para verificar? – Tower
Supongo que realmente depende de lo que está insertando, y cuáles son las consecuencias de insertarlo dos veces. ¿Fallará debido a una restricción de índice única, o entrará, y si es así, creará datos incorrectos? Queremos garantizar la coherencia, por lo que nuestros insertos suelen estar envueltos por IF [NOT] EXISTS (SELECCIONA 1 DE X DONDE ...).A veces, la cláusula WHERE contendrá un par de campos para que coincida; si está insertando algo, debe saber cuáles son y la mayoría de las entidades tendrán algún tipo de clave natural. –