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 un [objectname].script de creación sql por objeto en estos directorios. La jerarquía de tipos de objeto es así:

\Functions
\ Seguridad
\Security\Roles
\Seguridad\Esquemas
\Seguridad \ Usuarios
\Procedimientos almacenados
\Tabla

Si vuelca sus scripts al 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. Por lo que sé 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 derecho en base de datos - > Generar script SQL. Recomiendo configurar el "crear un archivo por objeto" en la pestaña de opciones) Luego puede confirmar estos archivos de texto a svn y hacer uso de las funciones de diff y registro de svn.

Tengo esto se vincula con un script por lotes 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 algún lugar accesible)

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

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

• Sistema centralizado de Control de Versiones - un sistema estándar donde los usuarios hacen check out / check in antes / después de trabajar en archivos, y los archivos se mantienen en un único servidor central

• Sistema de Control de Versiones Distribuido - un sistema donde el repositorio está siendo clonado, y cada clon es en realidad la copia de seguridad completa del repositorio, por lo que si algún servidor se bloquea, entonces cualquier repositorio clonado se puede utilizar 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 código fuente 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 ReadyRoll, que crea y administra un conjunto de scripts incrementales como un proyecto de Visual Studio.

En el Código SQL Control es posible especificar tablas de datos estáticas. Estos se almacenan en el control de código fuente como instrucciones INSERT.

Si está hablando de datos de prueba, le recomendamos que genere datos de prueba con una herramienta o a través de 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 mirar Liquibase ( http://www.liquibase.org / ). Incluso si no utiliza la herramienta en sí, maneja los conceptos de gestión de cambios de base de datos o refactorización bastante bien.

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

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

Una advertencia es que con una solución con scripts o de otra manera, las herramientas de RedGate son lo suficientemente suaves como para que sea fácil olvidarse de las realidades 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 columnas nuevas y eliminará todos los datos de la tabla. Generará advertencias pero he visto a gente pasar de eso. Hay un punto general aquí vale la pena hacer, creo, que solo se puede automatizar el control de versiones de BD y actualizar hasta ahora - las abstracciones son muy filtrantes.

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

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

1. Script fuera de su base de datos
2. Hacer cambios en los scripts o directamente en su servidor db
3. Sincronizar usando datos > Schema Compare

Es una solución perfecta de versionado de BD, y hace que la sincronización de BD sea muy fácil.

Es un buen enfoque guardar scripts de base de datos en 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 ser automatizado para que no tenga que hacer trabajo manual.

Creo que es importante tener una base de datos separada para cada desarrollador y no usar una base de datos compartida. De esa manera 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 están en qué estado de desarrollo y qué tablas contienen datos controlables de versiones, etc.

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 base de datos en evolución y no es adverso a la idea de usar Ruby, las migraciones de ActiveRecord son adecuadas para usted.

Las migraciones definen programáticamente las transformaciones de la base de datos utilizando un DSL de 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 comprobar en el control de versiones como cualquier otra pieza de código fuente.

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

También podría ver una solución de migraciones. Estos le permiten especificar su esquema de base de datos en código C# y subir y bajar su versión de base de datos usando MSBuild.

Actualmente estoy usando DbUp, y ha estado funcionando bien.

Cada base de datos debe estar bajo control de código fuente. Lo que falta es una herramienta para escribir automáticamente 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 código fuente. Si está utilizando SQL Server, entonces mi solución está aquí : http://dbsourcetools.codeplex.com / . Diviértanse. - Nathan.

Es simple.

1. Cuando el proyecto base esté listo, debe crear un script de base de datos completo. Este script está comprometido a 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 scripts de cambio nuevos.

4. Cuando la aplicación se lanza a producción, vuelve a 1 (pero luego será la versión sucesiva de curso).

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

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

Si tiene una base de datos pequeña y desea versionar todo, este script por lotes podría ayudar. Separa, comprime y comprueba un archivo MDF de la 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 puede usar Migraciones subsónicas para manejar eso. La ventaja es que puede migrar fácilmente hacia arriba o hacia abajo a cualquier versión específica.

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

Setup: Cree una tabla en cada base de datos que desee comprobar de forma incremental para mantener 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 la 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 funcionamiento normal: Puede tomar los resultados de este sql, y generar scripts sql para sólo los que está interesado en, y ponerlos en un control de código fuente 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 utiliza una intercalación no estándar en cualquiera de sus bases de datos, deberá reemplazar /* COLLATE */ con su intercalación de base de datos. es decir, COLLATE Latin1_General_CI_AI

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

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

Luego usamos herramientas propias para generar los scripts de actualización de esquemas y 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.

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 crear un script de cambios para cualquier versión de la base de datos y aplicarlo 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 las vistas y los 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 de C# que usaba SQLDMO para mapear todos los objetos SQL a una carpeta:

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

La aplicación 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 importan, 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 tantas veces como desee y volcará automáticamente sus objetos (tablas, vistas, procs, funciones, configuraciones sql) en SVN. Funciona como un encanto. Lo uso con Unfuddle (que me permite recibir alertas sobre checkins)

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 plugins de código abierto disponibles. Rodar su 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 control de versiones. Los archivos pueden obtener enorme rápido en el control de versiones, y hacer que todo su sistema de control de código fuente a ser lento (estoy recordando una historia de horror CVS en el momento).

Acabamos de empezar a usar Team Foundation Server. Si su base de datos es de tamaño mediano, visual studio tiene algunas buenas integraciones de proyectos con comparación integrada, comparación de datos, herramientas de refactorización de bases de datos, marco de pruebas 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 cifran objetos). Por lo tanto, lo que hemos hecho es almacenar solo nuestros objetos personalizados. Visual Studio Team foundation server funciona muy bien para que.

TFS Database chief arch. blog

MS TFS site

Estoy de acuerdo con la respuesta de ESV y por esa misma razón 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 mantenerse un lado largo hacia fuera del código fuente. Permite actualizaciones fáciles a los desarrolladores, así como UAT y Producción. La herramienta funciona en Sql Server y MySQL.

Algunas características del proyecto:

• Permite cambios de esquema
• Permite la población del árbol de valores
• Permite insertos de datos de prueba separados para, por ejemplo. UAT
• Permite la opción de reversión (no automatizada)
• Mantiene soporte para SQL server y Mysql
• Tiene la capacidad de importar su base de datos existente al control de versiones con un simple comando(solo sql server ... todavía trabajando en mysql)

El código está alojado en Google code. Por favor, echa un vistazo a Google code para obtener más información

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

Hace un tiempo encontré un módulo VB bas que usaba objetos DMO y VSS para obtener una base de datos completa con scripts fuera y dentro de VSS. Lo convertí en un script VB y lo publiqué aquí. Usted podría fácilmente sacar las llamadas VSS y utilizar las cosas DMO para generar todos los scripts, y luego llamar a SVN desde el mismo archivo por lotes que llama al VBScript para comprobar en?

Dave J

También estoy usando una versión en la base de datos almacenada a través de la familia de procedimientos database extended properties. Mi aplicación tiene scripts para cada paso de la 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 llega a la última versión de la aplicación. No hay ningún script que tenga la versión 'final' recta, incluso implementar en una base de datos limpia hace el despliegue a través de una serie de pasos de actualización.

Ahora lo que me gusta añadir es que he visto hace dos días una presentación en el campus MS sobre la nueva y próxima edición VS DB. La presentación se centró específicamente en este tema y me quedé fuera del agua. Definitivamente debe comprobarlo, las nuevas instalaciones se centran en mantener la definición del esquema en scripts T-SQL (CREATEs), un motor delta de tiempo de ejecución para comparar el esquema de implementación con el esquema definido y hacer las alteraciones delta e integración con la integración de código fuente, hasta e incluyendo la integración continua de MSBUILD para caídas de compilación automatizadas. La caída contendrá un nuevo tipo de archivo, el .archivos dbschema, que se pueden llevar 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, deberías echarles un vistazo: 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 bases de datos parece muy débil. Desde la organización del código hasta la implementación y el control de versiones, lo 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. Es necesario gestionar las actualizaciones de la base de datos en los sitios de los clientes.

Con el fin de manejar #1 necesitará una fuerte herramienta de diff/merge de base de datos. La mejor herramienta debe ser capaz de realizar la fusión automática tanto como sea posible, mientras que le permite resolver conflictos no controlados manualmente.

La herramienta perfecta debe manejar las operaciones de fusión utilizando un algoritmo de fusión de 3 vías que tenga en cuenta los cambios que se hicieron en la base de datos de ELLOS y la base de datos de la MINA, 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ébelo en http://www.sqlitecompare.com

Con el fin de manejar #2 usted 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 de un esquema SQL existente al esquema SQL más reciente y pueda construir una ruta de actualización para cada instalación de BD existente.

Echa un vistazo a 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 / . He utilizado de forma automatizada durante 2 años y funciona muy bien. Permite que nuestras compilaciones de BD sucedan de manera similar a una compilación de Java o C, excepto para 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. Que, para revertir o actualizar a una versión específica basta con comparar la versión actual de la base de datos con la instantánea de la versión de destino.

Por desgracia, si desea tener los datos bajo control de versión, así, puede utilizar xSQL Data Compare para generar scripts de cambio para su base de datos y añadir el .archivos sql en el control de versiones. A continuación, puede ejecutar estos scripts para revertir / actualizar a cualquier versión que desee. Tenga en cuenta que para la funcionalidad' revert ' necesita generar scripts de cambio que cuando se ejecuten harán que la Versión 3 sea la misma que la Versión 2 y para el 'actualizar' funcionalidad, es necesario generar scripts de cambio que hacen 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.