¿Cómo rastrea los cambios en la base de datos en el control de código fuente?

El seguimiento de los cambios en la base de datos directamente desde SSMS es posible utilizando varias herramientas de terceros. ApexSQL Source Control escribe automáticamente cualquier objeto de base de datos que esté incluido en el control de versiones. Las confirmaciones no pueden ser realizadas automáticamente por la herramienta. En su lugar, el usuario debe elegir qué cambios se confirmarán.

Al obtener cambios desde un repositorio, ApexSQL Source Control es consciente de la integridad referencial de una base de datos SQL. Por lo tanto, se creará un scripts de sincronización incluyendo todos los objetos dependientes que serán envueltos en una transacción, o bien todos los cambios serán aplicados en caso de que no se encuentre ningún error, o ninguno de los cambios seleccionados es aplicado. En cualquier caso, la integridad de la base de datos no se ve afectada.

Tengo que decir que creo que un proyecto de base de datos de visual studio también es una solución razonable para el dilema de control de código fuente. Si está configurado correctamente, puede ejecutar los scripts en la base de datos desde el IDE. Si su script es antiguo, obtenga el último, ejecútelo contra la base de datos. Tener un script que recrea todos los objetos también si es necesario, los nuevos objetos deben añadirse a este script también a mano, pero solo una vez

Me gusta que cada tabla, proc y función estén en su propio archivo.

La solución de un hombre pobre sería agregar un script de gancho pre-commit que vuelque el último esquema de bd en un archivo y haga que ese archivo se confirme en su repositorio SVN junto con su código. A continuación, puede diferenciar los archivos de esquema de la base de datos de cualquier revisión.

Acabo de confirmar la instrucción SQL-alter-adicional a la instrucción SQL-CreateDB-completa.

Rodar el suyo desde cero no sería muy factible, pero si usa una herramienta de comparación sql como Redgate SQL Compare SDK para generar sus archivos de cambio por usted, no tardaría mucho en rodar a la mitad lo que desea y luego simplemente verifique esos archivos en el control de código fuente. Hice algo similar para mí para actualizar los cambios de nuestros sistemas de desarrollo a nuestros sistemas en vivo en solo unas pocas horas.

En nuestro entorno, nunca cambiamos la base de datos manualmente: todos los cambios son realizados por scripts en el momento de la publicación, y los scripts se mantienen en el sistema de control de versiones. Una parte importante de este procedimiento es asegurarse de que todos los scripts se pueden ejecutar de nuevo contra la misma base de datos ¿los scripts son idempotentes?) sin pérdida de datos. Por ejemplo, si agrega una columna, asegúrese de no hacer nada si la columna ya está allí.

Su comentario sobre " sugerencias tienen el defecto de que requieren la dev para seguir algún procedimiento " es realmente un testigo. No es un defecto, es una característica. El control de versiones ayuda a los desarrolladores a seguir los procedimientos y hace que los procedimientos sean menos dolorosos. Si no desea seguir los procedimientos, no necesita control de versiones.

Aquí está Jeff Atwood en Obtenga Su Base de Datos Bajo Control de Versiones.

En SQL2000 genere cada objeto en su propio archivo, luego verifique todos en su control de código fuente. Deje que su control de origen maneje el historial de cambios.

En SQL 2005, necesitará escribir un poco de código para generar todos los objetos en archivos separados.

En un proyecto arreglé cuidadosamente en el diseño que todos los datos importantes en la base de datos se pueden recrear automáticamente desde lugares externos. Al iniciar la aplicación crea la base de datos si falta, y la rellena desde fuentes de datos externas, utilizando un esquema en el código fuente de la aplicación (y por lo tanto versionado con la aplicación). El nombre del almacén de bases de datos (un nombre de archivo sqlite, aunque la mayoría de los administradores de bases de datos permiten varias bases de datos) incluye una versión de esquema, y aumentamos la versión del esquema cada vez que confirmamos un cambio de esquema. Esto significa que cuando reiniciamos la aplicación a una nueva versión con un esquema diferente, se crea y rellena automáticamente un nuevo almacén de bases de datos. En caso de que tengamos que revertir una implementación a un esquema antiguo, la nueva ejecución de la versión antigua utilizará el antiguo almacén de bases de datos, por lo que podemos hacer degradaciones rápidas en caso de problemas.

Esencialmente, la base de datos actúa como un montón de aplicaciones tradicional, con el ventajas de la persistencia, la seguridad de las transacciones, la escritura estática (útil ya que usamos Python) y las restricciones de singularidad. Sin embargo, no nos preocupamos en absoluto por eliminar la base de datos y comenzar de nuevo, y la gente sabe que si intentan algún hack manual en la base de datos, entonces se revertirá en la próxima implementación, al igual que los hackeos de un estado de proceso se revertirán en el siguiente reinicio.

No necesitamos ningún script de migración ya que solo cambiamos el nombre del archivo de la base de datos y reiniciamos la aplicación y se reconstruye a sí mismo. Ayuda que las instancias de la aplicación estén divididas para usar una base de datos por cliente. También reduce la necesidad de copias de seguridad de bases de datos.

Este enfoque no funcionará si la compilación de la base de datos a partir de fuentes externas tarda más de lo que permitirá que la aplicación permanezca inactiva.

Si está utilizando. Net y le gusta el enfoque que Rails toma con las migraciones, entonces le recomendaría Migrator.Net .

Encontré un buen tutorial que recorre la configuración en Visual Studio. También proporciona un proyecto de ejemplo para referencia.

Desarrollamos una herramienta personalizada que actualiza nuestras bases de datos. El esquema de la base de datos se almacena en un archivo XML neutro que luego es leído y procesado por la herramienta. El esquema se almacena en SVN, y añadimos el comentario apropiado para mostrar lo que se ha cambiado. Funciona bastante bien para nosotros.

Si bien este tipo de solución es definitivamente exagerada para la mayoría de los proyectos, ciertamente hace la vida más fácil a veces.

Nuestros dba verifican periódicamente prod contra lo que está en SVN y eliminan cualquier objeto que no esté bajo control de código fuente. Solo se necesita una vez antes de que los devlopers nunca olviden poner algo en el control de código fuente de nuevo.

Tampoco permitimos que nadie mueva objetos a prod sin un script, ya que nuestros desarrolladores no tienen derechos de prod.

Para realizar un seguimiento de todos los cambios, como insertar actualización y eliminar, habrá una gran sobrecarga para el SVN. Es mejor realizar un seguimiento solo de los cambios ddl como (alter, drop, create) que cambia el esquema. Puede realizar este seguimiento de esquema fácilmente creando una tabla y un trgger para insertar datos en esa tabla. En cualquier momento que desee u puede obtener el estado de cambio consultando desde esa tabla Hay un montón de ejemplo aquí y aquí