Cómo hacer seguimiento de cambios de base de datos en el control de código fuente?

Question

Utilizamos SQL Server 2000/2005 y de la Bóveda o SVN en la mayoría de nuestros proyectos.No he encontrado una solución digna para la captura de esquema de base de datos/proc cambios en cualquier sistema de control de origen.

Nuestra solución actual es bastante engorroso y difícil de ejecutar la secuencia de comandos el objeto de cambiar y comprometerse a la base de datos).

Tenemos un montón de ideas de cómo hacer frente a este problema con algún desarrollo a la medida, pero yo prefiero instalar una herramienta existente (pagado herramientas están bien).

Así:¿cómo hacer un seguimiento de tu base de datos de cambios de código?¿Tienes algún herramientas recomendadas?

---

Editar:

Gracias por todas las sugerencias.Debido a las limitaciones de tiempo, prefiero no rodar mi propio aquí.Y la mayoría de las sugerencias tienen el defecto de que requieren el dev de seguir algún procedimiento.

En su lugar, una solución ideal sería monitor de la Base de datos SQL para cambios y confirmar cualquier cambio detectado en SCM.Por ejemplo, si SQL Server tenía un add-on que se puede grabar cualquier DML cambio con el usuario que hizo el cambio, luego de cometer el guión de ese objeto para SCM, yo estaría encantado.

Hablamos internamente los dos sistemas:1.En SQL 2005, el uso de objetos de permisos para restringir la alteración de un objeto hasta que hizo un "checkout".Entonces, el trabajo de protección del procedimiento secuencia de comandos en el SCM.2.Ejecutar un trabajo programado para detectar cualquier cambio y comprometerse con ellos (de forma anónima) para SCM.

Sería bueno si pudiera saltar el usuario-la parte de acción y el sistema de manejar todo esto de forma automática.

Answer 1

Use la edición de la base de datos de Visual Studio para escribir su base de datos. Funciona de maravilla y puede usar cualquier sistema de control de Fuente, por supuesto, mejor si tiene complementos VS. Esta herramienta también tiene una serie de otras características útiles. Míralos aquí en esta gran publicación de blog

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

o consulte MSDN para obtener la documentación oficial

Answer 2

El seguimiento de los cambios de la base de datos directamente desde SSMS es posible utilizando varias herramientas de terceros. ApexSQL Source Control crea automáticamente una secuencia de comandos para cualquier objeto de base de datos incluido en el control de versiones. La herramienta no puede realizar confirmaciones automáticamente. En cambio, el usuario debe elegir qué cambios se confirmarán.

Cuando se obtienen cambios desde un repositorio, ApexSQL Source Control es consciente de la integridad referencial de una base de datos SQL. Por lo tanto, creará una secuencia de comandos de sincronización que incluye todos los objetos dependientes que se incluirá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.

Answer 3

Debo decir que creo que un proyecto de base de datos de Visual Studio también es una solución razonable al dilema de control de 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. Tenga una secuencia de comandos que recrea todos los objetos también si es necesario, los nuevos objetos deben agregarse a esta secuencia de comandos también a mano, pero solo una vez

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

Answer 4

La solución de un pobre hombre sería agregar un script de enlace previo al compromiso que descargue el último esquema db en un archivo y que ese archivo se confirme en su repositorio SVN junto con su código. Luego, puede diferenciar los archivos de esquema db de cualquier revisión.

Answer 5

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

Answer 6

Rodar el tuyo desde cero no sería muy factible, pero si usas una herramienta de comparación SQL como Redgate SQL Compare SDK para generar sus archivos de cambio por usted, no le tomaría mucho tiempo desplegar lo que desea y luego simplemente verificar esos archivos en el control de código 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 7

En nuestro entorno, nunca cambiamos la base de datos manualmente: todos los cambios se realizan mediante scripts en el momento del lanzamiento, 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 puedan ejecutarse nuevamente en el mismo DB que 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í.

Tu comentario sobre & "; las sugerencias tienen el defecto de que requieren que el desarrollador siga algún procedimiento &"; Es realmente un cuento. 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.

Answer 8

En SQL2000 genera cada objeto en su propio archivo , luego revísalos en tu control de origen. Deje que su control de origen maneje el historial de cambios.

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

Answer 9

En un proyecto organizado por la atención cuidadosa en el diseño que todos los datos importantes en la base de datos puede ser vuelve a crear automáticamente desde lugares externos.En el inicio de la aplicación, se crea la base de datos si no está presente, y se rellena a partir de fuentes de datos externas, mediante un esquema en el código fuente de la aplicación (y por lo tanto, versionada con la aplicación).La base de datos el nombre de la tienda (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 del esquema, y aumentamos la versión del esquema cada vez que cometemos un cambio de esquema.Esto significa que cuando se reinicia la aplicación a una nueva versión con un esquema diferente que un nuevo almacén de base de datos se crea automáticamente y se rellena.Debemos revertir una implementación de un viejo esquema, a continuación, la nueva ejecución de la versión antigua utilizando el viejo almacén de base de datos, por lo que tenemos que hacer rápido, la rebaja en caso de problemas.

En esencia, la base de datos actúa como un tradicional montón de aplicación, con las ventajas de la persistencia, de la seguridad de la transacción, el tipo estático (muy útil ya que el uso de Python) y la particularidad de las restricciones.Sin embargo, no nos preocupamos en absoluto acerca de la eliminación de la base de datos y empezar de nuevo, y la gente sabe que si se trate de algún manual hack en la base de datos, a continuación, será revertido en la próxima implementación, como hacks de un proceso de estado conseguirá revertir en el próximo reinicio.

No necesitamos ningún scripts de migración ya que acaba de cambiar de base de datos de nombre de archivo y reinicie la aplicación y se reconstruye a sí mismo.Esto ayuda a que las instancias de aplicación son sharded el uso de una base de datos por cliente.También reduce la necesidad de la base de datos de copias de seguridad.

Este enfoque no funcionará si su base de datos de construir a partir de las fuentes externas tarda más de lo que te permitirá que la aplicación se quedan abajo.

Answer 10

Si está usando .Net y le gusta el enfoque que adopta Rails con Migraciones, entonces recomendaría Migrator .Net .

Encontré un bonito tutorial que explica cómo configurarlo en Visual Studio. También proporciona un proyecto de muestra para referencia.

Answer 11

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 comentarios apropiados para mostrar lo que se modificó. Funciona bastante bien para nosotros.

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

Answer 12

Nuestro dbas verifica periódicamente la producción contra lo que está en SVN y elimina cualquier objeto que no esté bajo el control de la fuente. Solo toma una vez antes de que los desarrolladores nunca olviden poner algo en el control de la fuente nuevamente.

Tampoco permitimos que nadie mueva objetos para producir sin un script ya que nuestros desarrolladores no tienen derechos de producción, esto es fácil de aplicar.

Answer 13

Para rastrear todos los cambios, 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 truco para insertar datos en esa tabla. Siempre que lo desee, puede obtener el estado de cambio consultando desde esa tabla Hay muchos ejemplos aquí y aquí