Aquí podría ser tu PUBLICIDAD


Base de datos de versiones de SQL Server

votos
288

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

Siempre querré tener al menos algunos datos allí (como menciona alumbra : tipos de usuario y administradores). También a menudo quiero una gran colección de datos de prueba generados para mediciones de rendimiento.

Publicado el 01/08/2008 a las 19:33
fuente por usuario Zack Peterson
En otros idiomas...        العربية       

29 respuestas

votos
169

Martin Fowler escribió mi artículo favorito sobre el tema, http://martinfowler.com/articles/evodb.html . Elijo no poner volcados de esquema en el control de la versión como lo sugieren alumb y otros 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, uso 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
    );

recibe 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. De nuevo, estos no son volcados de bases de datos. Más bien, cada script representa los cambios necesarios para pasar de una versión a la siguiente. Son la secuencia de comandos que aplica a su base de datos de producción para "actualizarla".

Sincronización Sandbox del desarrollador

  1. Una secuencia de comandos para realizar copias de seguridad, desinfectar y reducir una base de datos de producción. Ejecuta esto después de cada actualización al DB de producción.
  2. Una secuencia de comandos para restaurar (y modificar, 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 al DB de producción.

Una advertencia: mis pruebas automáticas se ejecutan en una base de datos correcta pero vacía, por lo que este consejo no se ajustará perfectamente a sus necesidades.

Respondida el 02/08/2008 a las 06:33
fuente por usuario ESV


Aquí podría ser tu PUBLICIDAD


votos
42

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 sus objetos a una jerarquía de carpetas organizada por tipo de objeto, con una creación de [objectname] .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 coloca los scripts en el mismo directorio raíz después de realizar los cambios, puede usar esto para actualizar su repositorio SVN y mantener un historial de ejecución de cada objeto individualmente.

Respondida el 26/08/2008 a las 08:23
fuente por usuario Dane

votos
38

Este es uno de los "problemas difíciles" que rodean el desarrollo. Hasta donde 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 con el botón derecho en la base de datos -> Generar script SQL. Recomiendo configurar "crear un archivo por objeto" en la pestaña de opciones). Luego puede enviar estos archivos de texto a svn y usar las funciones de registro y diff de svn.

Tengo esto vinculado 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 los productos Redgate ( http://www.red-gate.com/ ) para hacer las comparaciones. No son baratos, pero valen cada centavo.

Respondida el 01/08/2008 a las 08:28
fuente por usuario alumb

votos
37

En primer lugar, se debe elegir el sistema de control de versiones que es adecuado para usted:

  • sistema de control de versiones centralizado - un sistema estándar donde los usuarios echa un vistazo a / registro de entrada antes / después de que trabajan en los archivos y los archivos se mantienen en un solo servidor central

  • Sistema distribuido de control de versiones - un sistema en el que se clona el repositorio, y cada clon es en realidad la copia de seguridad completa del repositorio, por lo que si entonces cualquier repositorio clonado se pueden utilizar ningún servidor se bloquea, modificarla después de la elección del sistema adecuado para sus necesidades , tendrá que configurar el repositorio, que es el corazón de todo 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 -fuente-control-básico /

Después de la creación de un repositorio, y en el caso de un sistema de control de versiones central de una carpeta de trabajo, se puede leer este artículo . Se muestra cómo configurar control de código fuente en un entorno de desarrollo mediante:

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

  • Visual Studio y SQL Server Data Tools

  • Una herramienta tercera parte de control ApexSQL Fuente
Respondida el 24/06/2015 a las 10:36
fuente por usuario McRobert

votos
22

Aquí, en Puerta Roja ofrecemos una herramienta, SQL Source Control , que utiliza la tecnología de comparación de SQL para enlazar su base de datos con un repositorio SVN o TFS. Esta herramienta se integra en SSMS y le permite trabajar como lo haría normalmente, excepto que ahora le permite cometer los objetos.

Para un enfoque basado en las migraciones (más adecuado para implementaciones automatizadas), ofrecemos ReadyRoll , que crea y gestiona 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 control de código fuente como INSERT IGNORE declaraciones.

Si estamos hablando acerca de los datos de prueba, nos gustaría recomendar que o bien generar datos de prueba con una herramienta o por medio de una secuencia de comandos posterior a la implementación se define, o simplemente restaurar una copia de seguridad de producción para el entorno dev.

Respondida el 01/07/2010 a las 10:10
fuente por usuario David Atkinson

votos
20

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

Respondida el 16/09/2008 a las 07:16
fuente por usuario jeffjakub

votos
17

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

Además, SqlCompare tiene una API bastante documentada: puede escribir una aplicación de consola que sincronice su carpeta de scripts controlados desde origen con una base de datos de prueba de integración de CI al registrarse, de modo que cuando alguien verifique un cambio en el esquema desde su carpeta de scripts se implementa automáticamente junto con el cambio del 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 db local hasta un DB de desarrollo compartido (la mitad de nosotros, creo :)).

Una advertencia es que con una solución guionizada o de otro modo, las herramientas RedGate son lo suficientemente fluidas como para que sea fácil olvidarse de las realidades SQL que subyacen a la abstracción. Si cambia el nombre de todas las columnas en una tabla, SqlCompare no tiene forma de asignar las columnas antiguas a las nuevas columnas y eliminará todos los datos en la tabla. Generará advertencias, pero he visto personas que hacen clic para pasar de eso. Hay un punto general aquí que vale la pena, creo, que solo puedes automatizar el versionado y la actualización de bases de datos hasta el momento: las abstracciones son muy agudas.

Respondida el 15/10/2008 a las 10:44
fuente por usuario alexis.kennedy

votos
14

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

  1. Guión en su base de datos
  2. Realizar cambios en scripts o directamente en el servidor de db
  3. Sincronizar utilizando datos> Comparación de esquemas

Hace una solución de control de versiones DB perfecto, y hace que la sincronización de base de datos es una brisa.

Respondida el 25/02/2011 a las 09:18
fuente por usuario roman m

votos
14

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 construirá una nueva base de datos o actualizará cualquier base de datos existente al esquema en el control de versiones. De esta manera, no tiene que preocuparse por crear scripts de cambios (aunque aún puede hacerlo, por ejemplo, si desea cambiar el tipo de datos de una columna y necesita convertir los datos).

Respondida el 07/08/2008 a las 10:12
fuente por usuario Ray

votos
12

Es un buen método para guardar los scripts de la base de datos en el control de la versión 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 todas las secuencias de comandos de cambio. El manejo de los scripts debe automatizarse 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 esta forma, los desarrolladores pueden crear casos de prueba y fases de desarrollo independientemente de otros desarrolladores.

La herramienta de automatización debe contar con 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 la versión, etc.

Respondida el 24/09/2008 a las 07:11
fuente por usuario Silvercode

votos
11

También puede ver una solución de migraciones. Estos le permiten especificar el esquema de su base de datos en el 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.

Respondida el 06/08/2008 a las 11:51
fuente por usuario Lance Fisher

votos
10

No mencionó ningún detalle sobre su entorno o restricciones objetivo, por lo que puede no ser totalmente aplicable ... pero si está buscando una manera de seguir eficazmente un esquema DB en evolución y no son adversos a la idea de usar Ruby, las migraciones de ActiveRecord están a la vuelta de la esquina.

Las migraciones definen de forma programática las transformaciones de la base de datos con un Ruby DSL; cada transformación se puede aplicar o (por lo general) 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 otro código fuente.

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

Respondida el 02/08/2008 a las 06:54
fuente por usuario Matt

votos
9

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.

Respondida el 07/07/2009 a las 01:58
fuente por usuario Nathan Rozentals

votos
8

Es sencillo.

  1. Cuando el proyecto base está listo, debe crear un script de base de datos completo. Esta secuencia de comandos está comprometida 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 luego será una versión sucesiva, por supuesto).

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

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

Respondida el 16/05/2009 a las 12:31
fuente por usuario dariol

votos
7

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 al usar la información de la versión en sysobjects.

Configuración: Cree una tabla en cada base de datos que quiera verificar incrementalmente para contener la información de la versión desde la última vez que la verificó (vacía en la primera ejecución). Borre esta tabla si quiere 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 SQL para aquellos que le interesan y ponerlos en un control de 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 IGNORE  #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 IGNORE  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á reemplazarla /* COLLATE */con la intercalación de su base de datos. es decirCOLLATE Latin1_General_CI_AI

Respondida el 24/09/2008 a las 01:53
fuente por usuario Jonathan

votos
7

Debido a que nuestra aplicación tiene que funcionar en varios RDBMS, almacenamos nuestra definición de esquema en el control de versión utilizando el formato de par neutral (XML) de 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.

A continuación, utilizamos herramientas propias para generar la actualización de esquema y los scripts de actualización de datos de referencia necesarios para pasar de la versión X de la base de datos a la versión X + 1.

Respondida el 24/09/2008 a las 06:49
fuente por usuario Andrew Swan

votos
7

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

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

Respondida el 07/08/2008 a las 10:21
fuente por usuario Jon Galloway

votos
6

Escribí esta aplicación hace un tiempo, http://sqlschemasourcectrl.codeplex.com/ que escanear su MSFT SQL de DB con la frecuencia que desee y volcar automáticamente los objetos (tablas, vistas, procsos, funciones, configuración de SQL) en SVN. Funciona de maravilla. Yo lo uso con Unfuddle (que me permite obtener alertas sobre confirmaciones)

Respondida el 23/09/2010 a las 03:35
fuente por usuario ScaleOvenStove

votos
6

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

                Raíz
                    Nombre del servidor
                       Nombre de la base de datos
                          Objetos de esquema
                             Disparadores de base de datos *
                                .ddltrigger.sql
                             Funciones
                                ..function.sql
                             Seguridad
                                Roles
                                   Roles de aplicación
                                      .approle.sql
                                   Papeles de base de datos
                                      .role.sql
                                Schemas *
                                   .schema.sql
                                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 compararía entonces 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.

Respondida el 09/10/2008 a las 03:54
fuente por usuario Christopher Klein

votos
6

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 construyamos 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 esa secuencia de comandos y saber qué actualizaciones deben aplicarse. También tiene suficiente inteligencia para actualizar las vistas y los procedimientos almacenados según sea necesario.

Respondida el 07/08/2008 a las 12:00
fuente por usuario Chris Miller

votos
5

Estoy de acuerdo con la respuesta ESV y por esa razón exacta empecé un pequeño proyecto de un tiempo atrás para ayudar a mantener las actualizaciones de bases de datos en un archivo muy simple que podría entonces ser mantenidos un lado largo a cabo código fuente. Permite una fácil actualización a los desarrolladores, así como UAT y la producción. La herramienta funciona con mas de SQL Server y MySQL.

Algunas de las características del proyecto:

  • Permite cambios de esquema
  • Permite la población de árboles de valor
  • Permite inserciones de datos de prueba separados para por ejemplo. UAT
  • Permite opción para rollback (no automatizado)
  • Mantiene el soporte para el servidor SQL y MySQL
  • Tiene la capacidad de importar su base de datos existente en el control de versiones con un simple comando (SQL Server sólo se ... sigue trabajando en MySQL)

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

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

Respondida el 24/02/2011 a las 07:28
fuente por usuario Rolf Wessels

votos
5

Acabamos de empezar a utilizar Team Foundation Server. Si su base de datos es de tamaño mediano, 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 adapta muy bien a bases de datos muy grandes o de terceros (que cifran objetos). Entonces, lo que hemos hecho es almacenar solo nuestros objetos personalizados. Visual Studio / Team Foundation Server funciona muy bien para eso.

TFS Database chief arch. Blog

Sitio MS TFS

Respondida el 22/08/2008 a las 06:13
fuente por usuario TheEmirOfGroofunkistan

votos
5

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 rodar 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 control de versiones. Los archivos pueden ser muy rápidos en el control de versiones y hacer que todo el sistema de control de origen se vuelva lento (en este momento estoy recordando una historia de terror de CVS).

Respondida el 03/08/2008 a las 02:49
fuente por usuario engtech

votos
4

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 la versión (es decir, pasar de 1.1 a 1.2). Cuando se implementa, mira la versión actual y luego ejecuta los guiones uno por uno hasta que llega a la última versión de la aplicación. No hay una secuencia de comandos que tenga la versión final "recta", ni siquiera la implementación en una base de datos limpia. La implementación se realiza a través de una serie de pasos de actualización.

Ahora, lo que me gusta agregar es que hace dos días vi una presentación en el campus de MS sobre la nueva y próxima edición VS DB. La presentación se enfocó específicamente en este tema y salí volando del agua. Debería comprobarlo, las nuevas instalaciones se centran en mantener la definición del esquema en scripts T-SQL (CREATE), un motor delta en tiempo de ejecución para comparar el esquema de despliegue con el esquema definido y realizar ALTERs delta e integración con la integración del código fuente, hasta e incluyendo la integración continua de MSBUILD para gotas automáticas de compilación. La gota contendrá un nuevo tipo de archivo, los 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 en el blog sobre este tema con enlaces a las descargas de VSDE, debe verlas:http://rusanu.com/2009/05/15/version-control-and-your-database/

Respondida el 15/05/2009 a las 08:26
fuente por usuario Remus Rusanu

votos
4

Hace un tiempo encontré un módulo VB bas que usaba objetos DMO y VSS para obtener todo un archivo db con script en VSS. Lo convertí en un VB Script y lo publiqué aquí . ¿Podría sacar fácilmente las llamadas de VSS y usar las cosas de DMO para generar todas las secuencias de comandos, y luego llamar a SVN desde el mismo archivo por lotes que llama a VBScript para registrarlas?

Dave J

Respondida el 16/09/2008 a las 06:55
fuente por usuario Dave Jackson

votos
3

Su 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 bases de datos de Visual Studio. Sin esto, cualquier desarrollo de bases de datos se ve muy débil. Desde la organización del código de implementación para el control de versiones, se simplifica todo.

Respondida el 23/06/2015 a las 11:26
fuente por usuario Srivathsa Harish Venkataramana

votos
2

Visite DBGhost http://www.innovartis.co.uk/ . Lo he usado de forma automatizada durante 2 años y funciona muy bien. Permite que nuestras compilaciones de DB sucedan de forma similar a una compilación de Java o C, a excepción de la base de datos. Sabes a lo que me refiero.

Respondida el 02/11/2009 a las 11:17
fuente por usuario Kuberchaun

votos
2

En mi experiencia, la solución es doble:

  1. Debe gestionar 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 poder manejar el n. ° 1, necesitará una herramienta sólida de diferencia / combinación de bases de datos. La mejor herramienta debe ser capaz de realizar la fusión automática tanto como sea posible mientras le permite resolver los conflictos no controlados manualmente.

La herramienta perfecta debe manejar las operaciones de fusión mediante el uso de un algoritmo de combinación de 3 vías que tenga en cuenta los cambios que se realizaron en la base de datos THEIRS y 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 combinación de 3 vías para SQLite. Compruébelo en http://www.sqlitecompare.com

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

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

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

Buena suerte

Liron Levi

Respondida el 06/08/2009 a las 11:28
fuente por usuario Liron Levi

votos
1

Se recomienda usar herramientas de comparación para improvisar un sistema de control de versiones de su base de datos. Una buena alternativa son xSQL comparación de esquemas y xSQL Comparación de datos .

Ahora, si su objetivo es tener solamente el esquema de la base de datos bajo control de versiones sólo tiene que utilizar xSQL comparación de esquemas para generar xSQL instantáneas del esquema y añadir estos archivos en el control de versiones. Que, para revertir o actualizar a una versión específica simplemente comparar la versión actual de la base de datos con la instantánea para la versión de destino.

Por desgracia, si usted quiere tener los datos bajo control de versiones, así, puede utilizar xSQL Comparación de datos para generar secuencias de comandos de cambio para que la base de datos y agregar los archivos .sql en el control de versiones. A continuación, puede ejecutar estos scripts para revertir / actualización de cualquier versión que desee. Tenga en cuenta que para la funcionalidad 'Revert' que necesita para generar secuencias de comandos de cambio que, al ejecutarse hará que la versión 3 lo mismo que la versión 2 y la funcionalidad de la 'actualización', que necesita para generar secuencias de comandos de cambio que hacen lo contrario.

Por último, con algunos conocimientos básicos de programación por lotes puede automatizar todo el proceso mediante el uso de las versiones de línea de comandos de xSQL Comparación de esquemas y datos de comparación xSQL

Exención de responsabilidad: yo estoy afiliado a xSQL.

Respondida el 10/01/2017 a las 01:16
fuente por usuario Endi Zhupani


Aquí podría ser tu PUBLICIDAD