base de datos de gestión de procesos de construcción

Question

lo que existe opciones para administrar los scripts de base de datos y hacer un nuevo desarrollo para la base de datos:

Por ejemplo, la base de datos utilizada por un número de aplicaciones y hay un número de desarrolladores que trabajan con la base de datos, lo que se sean las mejores opciones para mantener la base de datos actualizada con los últimos cambios y cuál debería ser el proceso de cambios de implementación para la producción

veo dos opciones:

1. Microsoft visual Studio tiene un proyecto de base de datos, por lo que todo base de datos guiones deben añadir en el proyecto y la base de datos se pueden reconstruir de Visual Studio
2. Restaurar la base de datos de copia de seguridad y se aplican sólo a la base de datos nuevos guiones

lo que existe otra opción? ¿Cómo puedo gestionar el desarrollo de bases de datos? ¿Cuáles son las mejores prácticas? ¿Cuáles serán las ventajas y desventajas de las opciones que escribo arriba? ¿Cómo mantener nuevos scripts sql?

Entiendo que se debe utilizar el sistema de control de fuente, pero con las secuencias de comandos DB no es tan fácil como con la aplicación.

Creo que no será una solución universal, pero al menos soy interesante para los desarrolladores de DB la opinión de cómo se implementa en su empresa.

Answer 1

Liquibase es en mi humilde opinión la mejor herramienta. Es brutalmente simple en su enfoque, que es una de las razones por las que funciona tan bien.

Puede leer en el sitio cómo funciona, pero básicamente crea y administra una tabla simple que almacena un hash de cada script para determinar si ya ejecutó un script o no. También hay pre y post sql, y puedes eludir en condiciones ... hace prácticamente todo lo que quieras o necesites. También tiene integración maven, por lo que puede integrarse sin problemas a tu compilación.

Lo usé con mucho éxito en un proyecto grande (8 desarrolladores) y ahora no usaría nada más.

¡Y es gratis!

Answer 2

Actualmente usamos SVN y tenemos una carpeta "UpgradeScripts" donde todos los desarrolladores envían sus scripts.

Cada script tiene un prefijo generado en el formato upg_yyyymmddhhmmss_ScriptName.sql - Entonces, cuando se implementan, se ejecutan en un orden predefinido; manteniendo la base de datos consistente.

Esto se genera a través de la continuación de SQL y ejecutadas a través de un pre cometer gancho:

select 'upg_' + convert(varchar, SYSUTCDATETIME(), 112) 
    + replace(convert(varchar, SYSUTCDATETIME(), 8), ':', '') 
    + '-' 
    + 'MeaningfulScriptName' 

Otra técnica útil que utilizamos es asegurarse de que la diferencia entre los datos estáticos y no estáticos es clara; entonces en nuestra base de datos existe el esquema estándar "dbo" - que indica datos no estáticos que pueden cambiar entre entornos, y un esquema "estático". Todas las tablas de este esquema tienen identificadores estáticos, por lo que los desarrolladores saben que pueden usarlos en las enumeraciones y hacer referencia a los identificadores en las secuencias de comandos.

Si está buscando algo más formal, Red Gate tiene una utilidad llamada SQL Source Control.

O podría considerar usar el Data Tier Application framework.

Answer 3

Usamos DBGhost para controlar la base de datos. Los scripts para crear la base de datos actual se almacenan en TFS (junto con el código fuente) y luego DBGhost se utiliza para generar un script delta para actualizar un entorno a la versión actual. DBGhost también puede crear scripts delta para cualquier información estática/referencia/código.

Requiere un cambio de mentalidad del método tradicional, pero es una solución fantástica que no puedo recomendar. Si bien es un producto de terceros, se integra perfectamente en nuestro proceso automatizado de desarrollo e implementación.