¿Existe un sistema de control de versiones para los cambios en la estructura de la base de datos?

A menudo me encuentro con el siguiente problema.

Trabajo en algunos cambios a un proyecto que requieren nuevas tablas o columnas en la base de datos. Realizo modificaciones en la base de datos y continúo mi trabajo. Por lo general, recuerdo escribir los cambios para que puedan replicarse en el sistema en vivo. Sin embargo, no siempre recuerdo lo que he cambiado y no siempre recuerdo escribirlo.

Entonces, hago un empujón al sistema en vivo y obtengo un error grande y obvio de que no hay NewColumnX, ugh.

Independientemente del hecho de que esta puede no ser la mejor práctica para esta situación, ¿existe un sistema de control de versiones para bases de datos? No me importa la tecnología de base de datos específica. Solo quiero saber si existe. Si sucede que funciona con MS SQL Server, entonces genial.

En Ruby on Rails, hay un concepto de migración : un script rápido para cambiar la base de datos.

Genera un archivo de migración, que tiene reglas para aumentar la versión de base de datos (como agregar una columna) y reglas para degradar la versión (como eliminar una columna). Cada migración está numerada y una tabla realiza un seguimiento de su versión actual de db.

Para migrar , ejecuta un comando llamado "db: migrate" que mira su versión y aplica los scripts necesarios. Puede migrar hacia abajo de manera similar.

Los scripts de migración se mantienen en un sistema de control de versiones: cada vez que cambia la base de datos, ingresa un nuevo script y cualquier desarrollador puede aplicarlo para llevar su base de datos local a la última versión.

Soy un poco de la vieja escuela, ya que uso archivos fuente para crear la base de datos. En realidad, hay 2 archivos: project-database.sql y project-updates.sql: el primero para el esquema y los datos persistentes, y el segundo para las modificaciones. Por supuesto, ambos están bajo control de fuente.

Cuando la base de datos cambia, primero actualizo el esquema principal en project-database.sql, luego copio la información relevante a project-updates.sql, por ejemplo, las declaraciones ALTER TABLE. Entonces puedo aplicar las actualizaciones a la base de datos de desarrollo, probar, iterar hasta que esté bien hecho. Luego, verifique los archivos, pruebe nuevamente y solicite la producción.

Además, generalmente tengo una tabla en db - Config - como:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Luego, agrego lo siguiente a la sección de actualización:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

El db_versionúnico se cambia cuando se recrea la base de datos, y db_revisionme da una indicación de cuán lejos está la base de datos de la línea de base.

Podría mantener las actualizaciones en sus propios archivos separados, pero elegí unirlas todas y usar cortar y pegar para extraer secciones relevantes. Se requiere un poco más de limpieza, es decir, elimine ':' de $ Revision 1.1 $ para congelarlos.

MyBatis (anteriormente iBatis) tiene una migración de esquema , una herramienta para usar en la línea de comando. Está escrito en Java, aunque puede usarse con cualquier proyecto.

Para lograr una buena práctica de gestión de cambios en la base de datos, necesitamos identificar algunos objetivos clave. Por lo tanto, el Sistema de Migración del Esquema MyBatis (o Migraciones MyBatis para abreviar) busca:

• Trabaja con cualquier base de datos, nueva o existente
• Aproveche el sistema de control de fuente (por ejemplo, Subversion)
• Permita que los desarrolladores o equipos concurrentes trabajen independientemente
• Permitir conflictos muy visibles y fácilmente manejables.
• Permitir la migración hacia adelante y hacia atrás (evolucionar, delegar respectivamente)
• Hacer que el estado actual de la base de datos sea fácilmente accesible y comprensible
• Habilite las migraciones a pesar de los privilegios de acceso o la burocracia.
• Trabaja con cualquier metodología
• Fomenta las buenas prácticas consistentes.

Redgate tiene un producto llamado Control de código fuente SQL . Se integra con TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce y Git.

Recomiendo encarecidamente SQL delta . Solo lo uso para generar los scripts diff cuando termino de codificar mi función y verifico esos scripts en mi herramienta de control de fuente (Mercurial :))

Tienen tanto un servidor SQL como una versión de Oracle.

Me pregunto si nadie mencionó la herramienta de código abierto liquibase que está basada en Java y debería funcionar para casi todas las bases de datos que admiten jdbc. En comparación con los rieles, utiliza xml en lugar de rubí para realizar los cambios de esquema. Aunque no me gusta xml para lenguajes específicos de dominio, la gran ventaja de xml es que liquibase sabe cómo deshacer ciertas operaciones como

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Así que no necesitas manejar esto por tu cuenta

Las declaraciones de SQL puro o las importaciones de datos también son compatibles.

La mayoría de los motores de bases de datos deberían soportar volcar su base de datos en un archivo. Sé que MySQL lo hace, de todos modos. Esto solo será un archivo de texto, por lo que puede enviarlo a Subversion, o lo que sea que use. También sería fácil ejecutar un archivo diff en los archivos.

Si está utilizando SQL Server, sería difícil vencer a Data Dude (también conocido como la edición de base de datos de Visual Studio). Una vez que se familiarice con esto, es muy fácil hacer un esquema de comparación entre su versión controlada de origen de la base de datos y la versión en producción. Y con un clic puede generar su diff DDL.

Hay un video instructivo en MSDN que es muy útil.

Sé acerca de DBMS_METADATA y Toad, pero si alguien pudiera idear un Data Dude para Oracle, la vida sería realmente dulce.

Haga que sus declaraciones de tabla de creación iniciales en el controlador de versión, luego agregue declaraciones de tabla de alteración, pero nunca edite archivos, solo más archivos de alteración idealmente nombrados secuencialmente, o incluso como un "conjunto de cambios", para que pueda encontrar todos los cambios para una implementación particular.

La parte más difícil que puedo ver es el seguimiento de dependencias, por ejemplo, para una tabla de implementación particular B podría necesitar actualizarse antes de la tabla A.

Para Oracle, uso Toad , que puede volcar un esquema en varios archivos discretos (por ejemplo, un archivo por tabla). Tengo algunos scripts que administran esta colección en Perforce, pero creo que debería ser fácilmente posible en casi cualquier sistema de control de revisiones.

Eche un vistazo al paquete de Oracle DBMS_METADATA.

En particular, los siguientes métodos son particularmente útiles:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Una vez que esté familiarizado con su funcionamiento (se explica por sí mismo), puede escribir una secuencia de comandos simple para volcar los resultados de esos métodos en archivos de texto que se pueden poner bajo control de origen. ¡Buena suerte!

No estoy seguro si hay algo así de simple para MSSQL.

Escribo mis scripts de lanzamiento de db en paralelo con la codificación, y mantengo los scripts de lanzamiento en una sección específica del proyecto en SS. Si hago un cambio en el código que requiere un cambio de db, entonces actualizo el script de lanzamiento al mismo tiempo. Antes del lanzamiento, ejecuto el script de lanzamiento en un dev dev limpio (estructura copiada desde la producción) y hago mi prueba final en él.

He hecho esto de vez en cuando, administrando (o tratando de administrar) versiones de esquema. Los mejores enfoques dependen de las herramientas que tenga. Si puede obtener la herramienta de Quest Software "Schema Manager", estará en buena forma. Oracle tiene su propia herramienta inferior que también se llama "Administrador de esquemas" (¿confunde mucho?) Que no recomiendo.

Sin una herramienta automatizada (vea otros comentarios aquí sobre Data Dude), utilizará scripts y archivos DDL directamente. Elija un enfoque, documente y sígalo rigurosamente. Me gusta tener la capacidad de volver a crear la base de datos en cualquier momento, por lo que prefiero tener una exportación DDL completa de toda la base de datos (si soy el DBA), o del esquema del desarrollador (si estoy en el producto -desarrollo de modo).

PLSQL Developer, una herramienta de All Arround Automations, tiene un complemento para repositorios que funciona bien (pero no excelente) con Visual Source Safe.

De la web:

El complemento de control de versiones proporciona una estrecha integración entre el IDE de desarrollador de PL / SQL >> y cualquier sistema de control de versiones que admita la especificación de interfaz SCC de Microsoft. >> Esto incluye los sistemas de control de versiones más populares, como Microsoft Visual SourceSafe, >> Merant PVCS y MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio le permite invertir su esquema de base de datos en la herramienta y luego puede compararlo con bases de datos en vivo.

Ejemplo: invierta su esquema de desarrollo en ER Studio: compárelo con producción y enumerará todas las diferencias. Puede hacer un script de los cambios o simplemente empujarlos automáticamente.

Una vez que tenga un esquema en ER Studio, puede guardar el script de creación o guardarlo como un binario propietario y guardarlo en el control de versiones. Si alguna vez desea volver a una versión anterior del esquema, simplemente compruébelo y empújelo a su plataforma db.

Hay un "marco de migración de base de datos" PHP5 llamado Ruckusing. No lo he usado, pero los ejemplos muestran la idea, si usa el lenguaje para crear la base de datos cuando sea necesario, solo tiene que rastrear los archivos fuente.

Puede usar las herramientas de datos de Microsoft SQL Server en Visual Studio para generar scripts para objetos de base de datos como parte de un proyecto de SQL Server. Luego puede agregar los scripts al control de origen utilizando la integración de control de origen que está integrada en Visual Studio. Además, los proyectos de SQL Server le permiten verificar los objetos de la base de datos utilizando un compilador y generar scripts de implementación para actualizar una base de datos existente o crear una nueva.

Hemos usado MS Team System Database Edition con bastante buen éxito. Se integra con el control de versiones TFS y Visual Studio de manera más o menos fluida y nos permite administrar fácilmente los procesos almacenados, las vistas, etc. La resolución de conflictos puede ser una molestia, pero el historial de versiones se completa una vez hecho. A partir de entonces, las migraciones al control de calidad y la producción son extremadamente simples.

Sin embargo, es justo decir que es un producto de la versión 1.0 y no está exento de algunos problemas.

Schema Compare for Oracle es una herramienta diseñada específicamente para migrar cambios de nuestra base de datos Oracle a otra. Visite la URL a continuación para ver el enlace de descarga, donde podrá utilizar el software para una prueba completamente funcional.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

En ausencia de un VCS para los cambios de tabla, los he estado registrando en una wiki. Al menos entonces puedo ver cuándo y por qué se cambió. Está lejos de ser perfecto, ya que no todos lo están haciendo y tenemos varias versiones de productos en uso, pero mejor que nada.

Recomiendo uno de dos enfoques. Primero, invierta en PowerDesigner de Sybase. Edición de Empresa. Le permite diseñar modelos de datos físicos y mucho más. Pero viene con un repositorio que le permite registrar sus modelos. Cada nuevo registro puede ser una nueva versión, puede comparar cualquier versión con cualquier otra versión e incluso con lo que está en su base de datos en ese momento. Luego presentará una lista de todas las diferencias y preguntará cuál debe migrarse ... y luego construirá el script para hacerlo. No es barato, pero es una ganga al doble del precio y su ROI es de aproximadamente 6 meses.

La otra idea es activar la auditoría DDL (funciona en Oracle). Esto creará una tabla con cada cambio que realice. Si consulta los cambios desde la marca de tiempo en la que movió los cambios de la base de datos por última vez para producir en este momento, tendrá una lista ordenada de todo lo que ha hecho. Algunas cláusulas where para eliminar los cambios de suma cero como create table foo; seguido por drop table foo; y puedes construir FÁCILMENTE un script de mod. ¿Por qué mantener los cambios en una wiki? Eso es el doble del trabajo. Deje que la base de datos los rastree por usted.

Dos recomendaciones de libros: "Refactoring Databases" de Ambler y Sadalage y "Agile Database Techniques" de Ambler.

Alguien mencionó las migraciones de Rails. Creo que funcionan muy bien, incluso fuera de las aplicaciones Rails. Los usé en una aplicación ASP con SQL Server que estábamos en el proceso de pasar a Rails. Verifica los scripts de migración en el VCS. Aquí hay una publicación del pragmático Dave Thomas sobre el tema.