Quiero poner mis bases de datos bajo control de versiones. ¿Alguien tiene algún consejo o artículos recomendados para comenzar?

Siempre querré tener al menos algunos datos allí (como se menciona anteriormente: tipos de usuarios y administradores). A menudo, también quiero una gran colección de datos de prueba generados para mediciones de rendimiento.

Martin Fowler escribió mi artículo favorito sobre el tema, http://martinfowler.com/articles/evodb.html . Elijo no colocar los volcados de esquema bajo el control de versiones, ya que otros lo sugieren porque quiero una manera fácil de actualizar mi base de datos de producción.

Para una aplicación web donde tendré una única instancia de base de datos de producción, utilizo dos técnicas:

Scripts de actualización de base de datos

Una secuencia de comandos de actualización de base de datos que contiene el DDL necesario para mover el esquema de la versión N a N + 1. (Estos van en su sistema de control de versiones). Una tabla _version_history_, algo así como

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

obtiene una nueva entrada cada vez que se ejecuta un script de actualización que corresponde a la nueva versión.

Esto garantiza que sea fácil ver qué versión del esquema de la base de datos existe y que los scripts de actualización de la base de datos se ejecutan solo una vez. Nuevamente, estos no son volcados de la base de datos. Más bien, cada secuencia de comandos representa los cambios necesarios para pasar de una versión a la siguiente. Son el script que aplica a su base de datos de producción para "actualizarlo".

Desarrollador Sandbox Sincronización

1. Un script para hacer una copia de seguridad, desinfectar y reducir una base de datos de producción. Ejecute esto después de cada actualización a la base de datos de producción.
2. Un script para restaurar (y ajustar, si es necesario) la copia de seguridad en la estación de trabajo de un desarrollador. Cada desarrollador ejecuta este script después de cada actualización a la base de datos de producción.

Una advertencia: mis pruebas automatizadas se ejecutan contra una base de datos correcta pero sin esquema, por lo que este consejo no se adaptará perfectamente a sus necesidades.

El producto SQL Compare de Red Gate no solo le permite hacer comparaciones a nivel de objeto y generar scripts de cambio a partir de eso, sino que también le permite exportar los objetos de su base de datos a una jerarquía de carpetas organizada por tipo de objeto, con una [creación de nombre de objeto] .sql script por objeto en estos directorios. La jerarquía de tipo de objeto es así:

\ Funciones
\ Seguridad
\ Seguridad \ Roles
\ Seguridad \ Esquemas
\ Seguridad \ Usuarios
\ Procedimientos almacenados
\ Tablas

Si volca sus scripts en el mismo directorio raíz después de realizar cambios, puede usar esto para actualizar su repositorio SVN y mantener un historial de ejecución de cada objeto individualmente.

Este es uno de los "problemas difíciles" que rodean el desarrollo. Que yo sepa, no hay soluciones perfectas.

Si solo necesita almacenar la estructura de la base de datos y no los datos, puede exportar la base de datos como consultas SQL. (en Enterprise Manager: haga clic con el botón derecho en la base de datos -> Generar secuencia de comandos SQL. Recomiendo configurar "crear un archivo por objeto" en la pestaña de opciones). Luego puede confirmar estos archivos de texto en svn y utilizar las funciones de registro y diferencias de svn.

Tengo esto vinculado con un script Batch que toma un par de parámetros y configura la base de datos. También agregué algunas consultas adicionales que ingresan datos predeterminados, como los tipos de usuario y el usuario administrador. (Si quieres más información sobre esto, publica algo y puedo poner el script en un lugar accesible)

Si también necesita conservar todos los datos, le recomiendo mantener una copia de seguridad de la base de datos y utilizar los productos Redgate ( http://www.red-gate.com/ ) para hacer las comparaciones. No son baratos, pero valen cada centavo.

Primero, debe elegir el sistema de control de versiones que sea adecuado para usted:

• Sistema de control de versiones centralizado: un sistema estándar donde los usuarios desprotegen / ingresan antes / después de trabajar en archivos, y los archivos se mantienen en un solo servidor central

• Sistema de control de versiones distribuido: un sistema en el que se está clonando el repositorio, y cada clon es en realidad la copia de seguridad completa del repositorio, por lo que si algún servidor falla, se puede usar cualquier repositorio clonado para restaurarlo Después de elegir el sistema adecuado para sus necesidades , deberá configurar el repositorio, que es el núcleo de cada sistema de control de versiones. Todo esto se explica en el siguiente artículo: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-basics /

Después de configurar un repositorio y, en el caso de un sistema central de control de versiones, una carpeta de trabajo, puede leer este artículo . Muestra cómo configurar el control de origen en un entorno de desarrollo usando:

• SQL Server Management Studio a través del proveedor MSSCCI,

• Herramientas de datos de Visual Studio y SQL Server

• Una herramienta de terceros ApexSQL Source Control

Aquí en Red Gate ofrecemos una herramienta, SQL Source Control , que utiliza la tecnología SQL Compare para vincular su base de datos con un repositorio TFS o SVN. Esta herramienta se integra en SSMS y le permite trabajar como lo haría normalmente, excepto que ahora le permite confirmar los objetos.

Para un enfoque basado en migraciones (más adecuado para implementaciones automatizadas), ofrecemos Automatización de cambio de SQL (anteriormente llamado ReadyRoll), que crea y administra un conjunto de scripts incrementales como un proyecto de Visual Studio.

En SQL Source Control es posible especificar tablas de datos estáticos. Estos se almacenan en el control de origen como instrucciones INSERT.

Si habla de datos de prueba, le recomendamos que genere datos de prueba con una herramienta o mediante un script posterior a la implementación que defina, o simplemente restaure una copia de seguridad de producción en el entorno de desarrollo.

Es posible que desee ver Liquibase ( http://www.liquibase.org/ ). Incluso si no utiliza la herramienta en sí misma, maneja los conceptos de gestión de cambio de base de datos o refactorización bastante bien.

+1 para todos los que recomendaron las herramientas RedGate, con una recomendación adicional y una advertencia.

SqlCompare también tiene una API bien documentada: por lo que puede, por ejemplo, escribir una aplicación de consola que sincronice su carpeta de scripts controlados de origen con una base de datos de prueba de integración de CI en el registro, para que cuando alguien registre un cambio en el esquema desde su carpeta de scripts se implementa automáticamente junto con el cambio de código de la aplicación correspondiente. Esto ayuda a cerrar la brecha con los desarrolladores que se olvidan de propagar los cambios en su base de datos local hasta una base de datos de desarrollo compartida (creo que la mitad de nosotros :)).

Una advertencia es que con una solución programada o no, las herramientas de RedGate son lo suficientemente suaves como para que sea fácil olvidarse de las realidades de SQL subyacentes a la abstracción. Si cambia el nombre de todas las columnas de una tabla, SqlCompare no tiene forma de asignar las columnas antiguas a las nuevas columnas y eliminará todos los datos de la tabla. Generará advertencias, pero he visto gente haciendo clic más allá de eso. Creo que hay un punto general que vale la pena mencionar, que hasta ahora solo se puede automatizar el control de versiones y la actualización de la base de datos: las abstracciones son muy permeables.

Usamos DBGhost para administrar nuestra base de datos SQL. Luego coloca sus scripts para construir una nueva base de datos en su control de versiones, y o bien construirá una nueva base de datos o actualizará cualquier base de datos existente al esquema en el control de versiones. De esa manera, no tiene que preocuparse por crear scripts de cambio (aunque aún puede hacerlo, si, por ejemplo, desea cambiar el tipo de datos de una columna y necesita convertir datos).

Con VS 2010, use el proyecto de base de datos.

1. Script de su base de datos
2. Realice cambios en los scripts o directamente en su servidor db
3. Sincronizar usando Datos> Comparación de esquemas

Es una solución perfecta para el control de versiones de DB, y hace que la sincronización de DB sea muy fácil.

Es un buen enfoque guardar los scripts de la base de datos en el control de versiones con scripts de cambio para que pueda actualizar cualquier base de datos que tenga. También es posible que desee guardar esquemas para diferentes versiones para que pueda crear una base de datos completa sin tener que aplicar todos los scripts de cambio. El manejo de los scripts debe automatizarse para que no tenga que realizar trabajos manuales.

Creo que es importante tener una base de datos separada para cada desarrollador y no usar una base de datos compartida. De esa forma, los desarrolladores pueden crear casos de prueba y fases de desarrollo independientemente de otros desarrolladores.

La herramienta de automatización debe tener medios para manejar los metadatos de la base de datos, que indica qué bases de datos se encuentran en qué estado de desarrollo y qué tablas contienen datos controlables por versión, etc.

También puede buscar una solución de migraciones. Estos le permiten especificar su esquema de base de datos en código C #, y subir y bajar la versión de su base de datos usando MSBuild.

Actualmente estoy usando DbUp , y ha estado funcionando bien.

No mencionó ningún detalle sobre su entorno de destino o restricciones, por lo que esto puede no ser completamente aplicable ... pero si está buscando una manera de rastrear efectivamente un esquema de DB en evolución y no es adverso a la idea de usar Ruby, las migraciones de ActiveRecord están en tu callejón.

Las migraciones definen mediante programación las transformaciones de la base de datos utilizando un DSL Ruby; cada transformación se puede aplicar o (generalmente) revertir, lo que le permite saltar a una versión diferente de su esquema de base de datos en cualquier momento dado. El archivo que define estas transformaciones se puede verificar en el control de versiones como cualquier otra pieza de código fuente.

Debido a que las migraciones son parte de ActiveRecord , generalmente encuentran uso en aplicaciones Rails completas; sin embargo, puede usar ActiveRecord independientemente de Rails con un mínimo esfuerzo. Vea aquí un tratamiento más detallado del uso de las migraciones de AR fuera de Rails.

Cada base de datos debe estar bajo control de código fuente. Lo que falta es una herramienta para crear automáticamente una secuencia de comandos de todos los objetos de la base de datos, y "datos de configuración", en un archivo, que luego se puede agregar a cualquier sistema de control de origen. Si está utilizando SQL Server, mi solución está aquí: http://dbsourcetools.codeplex.com/ . Que te diviertas. - Nathan

Es sencillo.

1. Cuando el proyecto base esté listo, debe crear un script de base de datos completo. Este script está comprometido con SVN. Es la primera versión.

2. Después de eso, todos los desarrolladores crean scripts de cambio (ALTER ..., nuevas tablas, sprocs, etc.).

3. Cuando necesite la versión actual, debe ejecutar todos los nuevos scripts de cambio.

4. Cuando la aplicación se lanza a producción, vuelve a 1 (pero, por supuesto, será una versión sucesiva).

Nant te ayudará a ejecutar esos scripts de cambio. :)

Y recuerda. Todo funciona bien cuando hay disciplina. Cada vez que se confirma el cambio de la base de datos, también se comprometen las funciones correspondientes en el código.

Para hacer el volcado a un sistema de control de código fuente un poco más rápido, puede ver qué objetos han cambiado desde la última vez utilizando la información de versión en sysobjects.

Configuración: cree una tabla en cada base de datos que desee verificar de forma incremental para contener la información de la versión de la última vez que la comprobó (vacía en la primera ejecución). Borre esta tabla si desea volver a escanear toda su estructura de datos.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Modo de ejecución normal: puede tomar los resultados de este sql y generar scripts de sql solo para los que le interesan, y ponerlos en el control de origen de su elección.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Nota: Si usa una clasificación no estándar en cualquiera de sus bases de datos, deberá reemplazarla /* COLLATE */con la clasificación de su base de datos. es decirCOLLATE Latin1_General_CI_AI

Debido a que nuestra aplicación tiene que funcionar en múltiples RDBMS, almacenamos nuestra definición de esquema en el control de versiones utilizando el formato Torque (XML) neutral en la base de datos . También controlamos la versión de los datos de referencia para nuestra base de datos en formato XML de la siguiente manera (donde "Relación" es una de las tablas de referencia):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Luego, utilizamos herramientas propias para generar la actualización del esquema y los scripts de actualización de datos de referencia que se requieren para pasar de la versión X de la base de datos a la versión X + 1.

Si tienes una base de datos pequeña y quieres versionar todo, este script por lotes podría ayudar. Se separa, comprime y registra un archivo MDF de base de datos MSSQL en Subversion.

Si en su mayoría desea versionar su esquema y solo tiene una pequeña cantidad de datos de referencia, posiblemente pueda usar Migraciones SubSonic para manejar eso. El beneficio es que puede migrar fácilmente hacia arriba o hacia abajo a cualquier versión específica.

No almacenamos el esquema de la base de datos, almacenamos los cambios en la base de datos. Lo que hacemos es almacenar los cambios de esquema para que creemos un script de cambio para cualquier versión de la base de datos y lo apliquemos a las bases de datos de nuestros clientes. Escribí una aplicación de utilidad de base de datos que se distribuye con nuestra aplicación principal que puede leer ese script y saber qué actualizaciones deben aplicarse. También tiene suficiente inteligencia para actualizar vistas y procedimientos almacenados según sea necesario.

Tuvimos la necesidad de versionar nuestra base de datos SQL después de migrar a una plataforma x64 y nuestra versión anterior rompió con la migración. Escribimos una aplicación C # que usaba SQLDMO para asignar todos los objetos SQL a una carpeta:

                Raíz
                    Nombre del servidor
                       Nombre de la base de datos
                          Objetos de esquema
                             Desencadenantes de la base de datos *
                                .ddltrigger.sql
                             Las funciones
                                ..function.sql
                             Seguridad
                                Roles
                                   Roles de aplicación
                                      .approle.sql
                                   Roles de base de datos
                                      .role.sql
                                Esquemas *
                                   .schema.sql
                                Los usuarios
                                   .user.sql
                             Almacenamiento
                                Catálogos de texto completo *
                                   .fulltext.sql
                             Procedimientos almacenados
                                ..proc.sql
                             Sinónimos *
                                .synonym.sql
                             Mesas
                                ..table.sql
                                Restricciones
                                   ... chkconst.sql
                                   ... defconst.sql
                                Índices
                                   ... index.sql
                                Llaves
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Disparadores
                                   ... trigger.sql
                             Tipos
                                Tipos de datos definidos por el usuario
                                   ..uddt.sql
                                Colecciones de esquemas XML *
                                   ..xmlschema.sql
                             Puntos de vista
                                ..view.sql
                                Índices
                                   ... index.sql
                                Disparadores
                                   ... trigger.sql

La aplicación luego compararía la versión recién escrita con la versión almacenada en SVN y, si hubiera diferencias, actualizaría SVN. Determinamos que ejecutar el proceso una vez por noche era suficiente ya que no realizamos tantos cambios en SQL. Nos permite realizar un seguimiento de los cambios en todos los objetos que nos interesan, además de que nos permite reconstruir nuestro esquema completo en caso de un problema grave.

Escribí esta aplicación hace un tiempo, http://sqlschemasourcectrl.codeplex.com/ que escaneará sus bases de datos SQL de MSFT con la frecuencia que desee y descargará automáticamente sus objetos (tablas, vistas, procs, funciones, configuraciones sql) en SVN. Funciona de maravilla. Lo uso con Unfuddle (que me permite recibir alertas en los registros)

La solución típica es volcar la base de datos según sea necesario y hacer una copia de seguridad de esos archivos.

Dependiendo de su plataforma de desarrollo, puede haber complementos de código abierto disponibles. Hacer tu propio código para hacerlo suele ser bastante trivial.

Nota: es posible que desee hacer una copia de seguridad del volcado de la base de datos en lugar de ponerlo en el control de versiones. Los archivos pueden volverse enormes rápidamente en el control de versiones y hacer que todo su sistema de control de fuente se vuelva lento (estoy recordando una historia de horror de CVS en este momento).

Acabamos de empezar a usar Team Foundation Server. Si su base de datos es de tamaño mediano, entonces Visual Studio tiene algunas buenas integraciones de proyectos con herramientas integradas de comparación, comparación de datos, refactorización de bases de datos, marco de prueba de bases de datos e incluso herramientas de generación de datos.

Pero ese modelo no se ajusta muy bien a bases de datos muy grandes o de terceros (que encriptan objetos). Entonces, lo que hemos hecho es almacenar solo nuestros objetos personalizados. El servidor de base de Visual Studio / Team funciona muy bien para eso.

Jefe de base de datos TFS arch. Blog

Sitio de MS TFS

Estoy de acuerdo con la respuesta de ESV y por esa razón exacta comencé un pequeño proyecto hace un tiempo para ayudar a mantener las actualizaciones de la base de datos en un archivo muy simple que luego podría mantener un código fuente largo. Permite actualizaciones fáciles para los desarrolladores, así como para UAT y Production. La herramienta funciona en Sql Server y MySql.

Algunas características del proyecto:

• Permite cambios de esquema
• Permite valorar la población arbórea
• Permite insertar datos de prueba por separado, por ejemplo. UAT
• Permite la opción de reversión (no automatizado)
• Mantiene soporte para servidor SQL y Mysql
• Tiene la capacidad de importar su base de datos existente en el control de versiones con un simple comando (solo servidor sql ... aún trabajando en mysql)

El código está alojado en el código de google. Consulte el código de Google para obtener más información.

http://code.google.com/p/databaseversioncontrol/

Hace un tiempo, encontré un módulo bas de VB que usaba objetos DMO y VSS para obtener un db completo con script y entrar en VSS. Lo convertí en un script VB y lo publiqué aquí . ¿Podría sacar fácilmente las llamadas VSS y usar el material DMO para generar todos los scripts, y luego llamar a SVN desde el mismo archivo por lotes que llama al VBScript para registrarlos?

Dave J

También estoy usando una versión en la base de datos almacenada a través de la familia de procedimientos de propiedades extendidas de la base de datos. Mi aplicación tiene scripts para cada paso de versión (es decir, pasar de 1.1 a 1.2). Cuando se implementa, mira la versión actual y luego ejecuta los scripts uno por uno hasta que alcanza la última versión de la aplicación. No hay un script que tenga la versión 'final' directa, incluso la implementación en una base de datos limpia se implementa a través de una serie de pasos de actualización.

Ahora, lo que me gusta agregar es que he visto hace dos días una presentación en el campus de MS sobre la nueva y próxima edición VS DB. La presentación se centró específicamente en este tema y me quedé sin aliento. Definitivamente debe verificarlo, las nuevas instalaciones se centran en mantener la definición del esquema en los scripts T-SQL (CREATE), un motor delta en tiempo de ejecución para comparar el esquema de implementación con el esquema definido y hacer las alteraciones delta y la integración con la integración del código fuente, hasta e incluyendo la integración continua de MSBUILD para las caídas de compilación automatizadas. La caída contendrá un nuevo tipo de archivo, los archivos .dbschema, que pueden llevarse al sitio de implementación y una herramienta de línea de comandos puede hacer los 'deltas' reales y ejecutar la implementación. Tengo una entrada de blog sobre este tema con enlaces a las descargas de VSDE, debe consultarlas:http://rusanu.com/2009/05/15/version-control-and-your-database/

Es una pregunta muy antigua, sin embargo, muchos están tratando de resolver esto incluso ahora. Todo lo que tienen que hacer es investigar sobre los proyectos de base de datos de Visual Studio. Sin esto, cualquier desarrollo de base de datos parece muy débil. Desde la organización del código hasta la implementación y el control de versiones, simplifica todo.

En mi experiencia, la solución es doble:

1. Debe manejar los cambios en la base de datos de desarrollo que realizan varios desarrolladores durante el desarrollo.

2. Debe manejar las actualizaciones de la base de datos en los sitios de los clientes.

Para manejar el n. ° 1, necesitará una sólida herramienta de combinación / diferencia de base de datos. La mejor herramienta debería ser capaz de realizar la fusión automática tanto como sea posible mientras le permite resolver conflictos no manejados manualmente.

La herramienta perfecta debe manejar las operaciones de fusión mediante el uso de un algoritmo de fusión de 3 vías que tenga en cuenta los cambios que se realizaron en la base de datos THEIRS y la base de datos MINE, en relación con la base de datos BASE.

Escribí una herramienta comercial que proporciona soporte de fusión manual para bases de datos SQLite y actualmente estoy agregando soporte para el algoritmo de fusión de 3 vías para SQLite. Compruébalo en http://www.sqlitecompare.com

Para manejar el n. ° 2, necesitará un marco de actualización en su lugar.

La idea básica es desarrollar un marco de actualización automática que sepa cómo actualizar desde un esquema SQL existente al esquema SQL más nuevo y pueda construir una ruta de actualización para cada instalación de base de datos existente.

Consulte mi artículo sobre el tema en http://www.codeproject.com/KB/database/sqlite_upgrade.aspx para tener una idea general de lo que estoy hablando.

Buena suerte

Liron Levi

Echa un vistazo a DBGhost http://www.innovartis.co.uk/ . Lo he usado de manera automatizada durante 2 años y funciona muy bien. Permite que nuestras compilaciones de bases de datos sucedan como ocurre con una compilación de Java o C, a excepción de la base de datos. Sabes a lo que me refiero.

Sugeriría usar herramientas de comparación para improvisar un sistema de control de versiones para su base de datos. Una buena alternativa son xSQL Schema Compare y xSQL Data Compare .

Ahora, si su objetivo es tener solo el esquema de la base de datos bajo control de versiones, simplemente puede usar xSQL Schema Compare para generar instantáneas xSQL del esquema y agregar estos archivos en su control de versiones. Luego, para revertir o actualizar a una versión específica, simplemente compare la versión actual de la base de datos con la instantánea de la versión de destino.

Por desgracia, si también desea tener los datos bajo control de versiones, puede usar xSQL Data Compare para generar scripts de cambio para su base de datos y agregar los archivos .sql en su control de versiones. Luego puede ejecutar estos scripts para revertir / actualizar a cualquier versión que desee. Tenga en cuenta que para la funcionalidad 'revertir' necesita generar scripts de cambio que cuando se ejecuten harán que la Versión 3 sea igual a la Versión 2 y para la funcionalidad 'actualizar', necesita generar scripts de cambio que hagan lo contrario.

Por último, con algunas habilidades básicas de programación por lotes, puede automatizar todo el proceso utilizando las versiones de línea de comandos de xSQL Schema Compare y xSQL Data Compare

Descargo de responsabilidad: estoy afiliado a xSQL.