¿Cómo mantener los procedimientos almacenados y otros scripts en SVN/Otro repositorio?

Question

¿Alguien puede proporcionar algunos ejemplos reales sobre la mejor manera de conservar archivos de script para vistas, procedimientos almacenados y funciones en un repositorio SVN (u otro)?

Obviamente, una solución es tener los archivos de script para todos los diferentes componentes en un directorio o más en algún lugar y simplemente usar TortoiseSVN o similar para mantenerlos en SVN. Luego, cada vez que se debe realizar un cambio, cargo el script en Management Studio, etc. .Realmente no quiero esto.

Lo que realmente preferiría es algún tipo de script por lotes que pueda ejecutar periódicamente (¿todas las noches?) que exporte todos los procedimientos/vistas almacenados, etc. que hayan cambiado en un período de tiempo determinado y luego los envíe a SVN.

¿Ideas?

Answer 1

A mí me parece que no quieres utilizar el control de revisiones correctamente.

Obviamente, una solución es tener los archivos de script para todos los diferentes componentes en un directorio o más en algún lugar y simplemente usar TortoisSVN o similares para mantenerlos en SVN

Esto es lo que se debe hacer.Tendría su copia local en la que está trabajando (desarrollando algo nuevo, modificando lo antiguo, etc.) y, a medida que se terminen los componentes/procedimientos/etc. individuales, los confirmaría individualmente hasta que tenga que comenzar el proceso de nuevo.

Confirmar código a medio hacer sólo porque han pasado 'X' tiempo desde la última vez que se confirmó es descuidado y garantiza que causará dolor a cualquier otra persona que use el repositorio.

Answer 2

Considero que es mejor tratar los procedimientos almacenados como cualquier otro código compilable:El código reside en el repositorio, usted lo verifica para realizar cambios y lo carga en su herramienta de desarrollo para compilar o implementar el código.

Answer 3

Puede crear un archivo por lotes y programarlo:

• eliminar el contenido de su directorio de scripts
• usando algo como ExportarSQLScript para exportar todos los objetos a script/scripts
• compromiso svn

Tenga en cuenta:Que aunque tendrá los objetos bajo control de fuente, no tendrá los datos ni su progresión (¿es un campo renombrado o 1 campo nuevo y 1 eliminado?).

Este enfoque está bien para mantener el historial de cambios.Pero, por supuesto, nunca deberías comprometerte automáticamente con la "compilación de producción" (a menos que te gusten las compilaciones rotas).

Aunque no lo pediste:Este enfoque tampoco producirá un conjunto de scripts que actualicen una base de datos actual.Solo tendrás scripts de creación iniciales.El registro de la progresión de los datos y la creación de scripts de actualización va más allá de los sistemas básicos de control de fuentes.

Answer 4

Yo lo recomiendo puerta roja SQL Compare para esto: le permite comparar versiones de bases de datos y generar scripts de cambios; también es bastante fácil de programar.

Answer 5

Según su pregunta ampliada, realmente desea utilizar activadores DDL.Verificar Este artículo que detalla cómo crear un sistema de registro de cambios para su base de datos.

Answer 6

Sin embargo, no estoy seguro de su rango de precios. Fantasma DB podría ser una opción para ti.

No trabajo para esta empresa (ni soy dueño del producto), pero en mi investigación sobre el mismo tema, este producto parecía bastante prometedor.

Answer 7

Debería haber sido un poco más descriptivo.La base de datos en cuestión es para un sistema ERP interno y, por lo tanto, no tenemos muchas versiones de nuestra base de datos, solo Producción/Pruebas/Desarrollo.Cuando hemos realizado una solicitud de cambio, alguna característica nueva y sofisticada o algo así, simplemente ejecutamos un script o una serie de scripts para actualizar los procedimientos en cuestión en la base de datos de Pruebas, si todo está bien, entonces hacemos lo mismo con Producción.

Así que realmente no busco un script de esquema completo per se, solo algo que pueda realizar un seguimiento de las diversas ediciones de los procedimientos almacenados a lo largo del tiempo.Por ejemplo, PROCESS_INVOICE hace cosas.Se actualiza de forma menor en marzo.Algún tiempo después, digamos en mayo, se descubre que, en un caso raro, a los clientes se les factura dos veces (o algún otro caso loco).Me gustaría poder ver qué ha sucedido con el tiempo con este procedimiento.Actualmente no tengo la forma en que está configurado el entorno de desarrollo aquí, lo cual estoy intentando cambiar.

Answer 8

Puedo recomendar DBPro, que forma parte de Visual Studio Team Edition.Lo he estado usando durante algunos meses para almacenar todas las partes de la base de datos en Team Foundation Server, así como para la implementación y comparación de bases de datos, etc.

Por supuesto, como alguien más mencionó, depende de su entorno y rango de precios.

Answer 9

Escribí una utilidad para volcar todas las partes relevantes de mi base de datos en una estructura de directorios en la que uso SVN.Nunca intenté incorporarlo al Manager pero, si estás interesado, está aquí: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

Es gratis y, como lo ejecuto regularmente, sabes que cualquier error se soluciona rápidamente.

Answer 10

Siempre puedes intentar integrar SourceSafe con SQL Server.Aquí hay un comienzo rápido: enlace .Para trabajar con él debes tener Managment Studio Developers Edition.