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

Question

Usamos SQL Server 2000/2005 y Vault o SVN en la mayoría de nuestros proyectos. No he encontrado una solución decente para capturar cambios de esquema/proc de base de datos en cualquiera de los sistemas de control de origen.

Nuestra solución actual es bastante engorrosa y difícil de aplicar (script el objeto que cambia y lo confía a la base de datos).

Tenemos muchas ideas de cómo abordar este problema con algún desarrollo personalizado, pero prefiero instalar una herramienta existente (las herramientas de pago están bien).

Entonces, ¿cómo hace un seguimiento de los cambios en el código de su base de datos? ¿Tienes alguna herramienta recomendada?

---

Editar:

Gracias por todas las sugerencias. Debido a las limitaciones de tiempo, preferiría no hacer mi propio aquí. Y la mayoría de las sugerencias tienen el inconveniente de que requieren que el desarrollador siga algún procedimiento.

En su lugar, una solución ideal supervisaría la base de datos SQL en busca de cambios y confirmaría cualquier cambio detectado en SCM. Por ejemplo, si SQL Server tuviera un complemento que pudiera registrar cualquier cambio en DML con el usuario que realizó el cambio, entonces, debe enviar el script de ese objeto a SCM, estaría encantado.

Hablamos internamente acerca de dos sistemas: 1. En SQL 2005, use permisos de objeto para restringir la alteración de un objeto hasta que haya realizado una "extracción". Luego, el procedimiento de registro lo guiaría al SCM. 2. Ejecute un trabajo programado para detectar cualquier cambio y enviarlo (anónimamente) a SCM.

Sería bueno si pudiera saltear la parte de acción del usuario y hacer que el sistema maneje todo esto automáticamente.

Answer 1

Utilice Visual Studio database edition para crear una secuencia de comandos de su base de datos. Funciona como un amuleto y puede usar cualquier sistema de control de fuente, por supuesto, mejor si tiene complementos VS. Esta herramienta también tiene otras características útiles. Compruebe a cabo aquí en esta gran entrada de blog

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

o echa un vistazo a MSDN para la documentación oficial

Answer 2

La solución de un pobre hombre sería agregar una secuencia de comandos de enlace de precompilación que vuelque el último esquema de base de datos en un archivo y que ese archivo se confirme en su repositorio de SVN junto con su código. Luego, puede diferenciar los archivos de esquema db de cualquier revisión.

Answer 3

Acabo de enviar el SQL-alter-Statement adicional a la declaración SQL-CreateDB completa.

Answer 4

Aquí está Jeff Atwood en Get Your Database Under Version Control.

Answer 5

En SQL2000 generar cada objeto en su propio archivo, a continuación, comprobar a todos en el 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.

Answer 6

Tengo que decir que creo que un proyecto de base de datos de estudio visual también es una solución razonable para el dilema de control de origen.Si está configurado correctamente, puede ejecutar los scripts contra la base de datos desde el IDE. Si su script es viejo, obtenga lo último, ejecútelo contra el DB. Tenga una secuencia de comandos que recrea todos los objetos también si necesita, los nuevos objetos se deben agregar a este script también a mano, pero solamente una vez

Me gusta cada tabla, proc y función estar en su propio archivo.

Answer 7

Nuestro dbas comprueba periódicamente la piquera contra lo que está en SVN y elimina cualquier objeto que no esté bajo control de origen. Solo toma una vez antes de que los devlopers nunca olviden poner algo en control de fuente de nuevo.

Tampoco permitimos que nadie mueva objetos a prod sin una secuencia de comandos ya que nuestros desarrolladores no tienen derechos de pellizco esto es fácil de aplicar.

Answer 8

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

Answer 9

En nuestro entorno, nunca cambiamos la base de datos manualmente: todos los cambios se realizan mediante scripts en el momento de la liberació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 puedan ejecutar de nuevo contra el mismo DB; 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 "las sugerencias tienen el inconveniente de que requieren que el desarrollador siga algún procedimiento" es realmente revelador. 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 quiere seguir los procedimientos, no necesita control de versiones.

Answer 10

En un proyecto organizó con atención cuidadosa en el diseño que todos los datos importantes en la base de datos pueden recrearse automáticamente desde lugares externos. Al inicio, 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 la base de datos (un nombre de archivo sqlite aunque la mayoría de los administradores de bases de datos permiten múltiples 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 completa automáticamente un nuevo almacén de base de datos. En caso de que tengamos que revertir una implementación a un esquema anterior, la nueva versión de la versión anterior utilizará el antiguo almacén de base de datos, por lo que podremos realizar degradaciones rápidas en caso de problemas.

Básicamente, la base de datos actúa como un montón de aplicaciones tradicionales, con las ventajas de persistencia, seguridad de transacciones, tipado estático (útil ya que usamos Python) y restricciones de exclusividad. Sin embargo, no nos preocupamos en absoluto por eliminar la base de datos y empezar de nuevo, y las personas saben que si intentan realizar algún corte manual en la base de datos, se revertirá en la siguiente implementación, al igual que se revertirán los hacks de un estado de proceso. en el próximo reinicio

No necesitamos ningún script de migración ya que solo cambiamos el nombre de archivo de la base de datos y reiniciamos la aplicación y se reconstruye a sí mismo. Ayuda a que las instancias de la aplicación se fragmenten 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 desde las fuentes externas tarda más de lo que permitirá que la aplicación permanezca inactiva.

Answer 11

Si está utilizando.Net y, al igual que el enfoque que toma Rails con Migrations, entonces recomendaría Migrator.Net.

Encontré un nice tutorial que describe su configuración en Visual Studio. También proporciona un proyecto de muestra para referencia.

Answer 12

Desarrollamos una herramienta personalizada que actualiza nuestras bases de datos. El esquema de la base de datos se almacena en un archivo XML neutral de base de datos que luego es leído y procesado por la herramienta. El esquema se almacena en SVN y agregamos el comentario apropiado para mostrar lo que se cambió. Funciona bastante bien para nosotros.

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

Answer 13

Para rastrear todo el cambio, como insertar actualización y eliminar, habrá una gran sobrecarga para el SVN. Es mejor rastrear solo los cambios ddl como (alterar, soltar, crear) que cambia el esquema. Puede hacer 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 conseguir el cambio de estado mediante la consulta de esa tabla Hay una gran cantidad de here ejemplo y base de datos de seguimiento here

Answer 14

cambia directamente de SSMS es posible utilizando varias herramientas de 3 ª parte. ApexSQL Source Control scripts automáticamente cualquier objeto de base de datos que se incluye en el control de versiones. La herramienta no puede realizar automáticamente los commits. En cambio, el usuario debe elegir qué cambios se comprometerán.

Al obtener cambios de un repositorio, ApexSQL Source Control conoce una integridad referencial de la base de datos SQL. Por lo tanto, creará una secuencia de comandos de sincronización que incluye todos los objetos dependientes que se envolverán en una transacción, por lo que se aplicarán todos los cambios en caso de que no se encuentre ningún error o no se aplique ninguno de los cambios seleccionados. En cualquier caso, la integridad de la base de datos no se ve afectada.