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

08-06-2019
|

Pregunta

A menudo me encuentro con el siguiente problema.

Trabajo en algunos cambios en un proyecto que requieren nuevas tablas o columnas en la base de datos.Hago las modificaciones de la base de datos y continúo mi trabajo.Por lo general, recuerdo anotar 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, presiono el sistema en vivo y obtengo un error grande y obvio que indica que no hay NewColumnX, puaj.

Independientemente del hecho de que esta pueda 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.Sólo quiero saber si existe alguno.Si funciona con MS SQL Server, entonces genial.

Solución

En Ruby on Rails, existe el 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 la 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 base de datos.

A migrar hacia arriba, ejecuta un comando llamado "db:migrate" que analiza su versión y aplica los scripts necesarios.Puedes migrar hacia abajo de manera similar.

Los scripts de migración en sí 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.

Otros consejos

Soy un poco anticuado, 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 código fuente.

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

Además, normalmente tengo una tabla en la base de datos - Config - como por ejemplo:

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 sólo se modifica cuando se recrea la base de datos, y el db_revision me da una indicación de qué tan lejos está la base de datos de la línea de base.

Podría mantener las actualizaciones en sus propios archivos separados, pero elegí combinarlas todas y usar cortar y pegar para extraer las secciones relevantes.Es necesario hacer un poco más de limpieza, es decir, eliminar ':' de $Revisión 1.1 $ para congelarlos.

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

Para lograr una buena práctica de gestión de cambios en la base de datos, necesitamos identificar algunos objetivos clave.Así, el Sistema de Migración de Esquemas MyBatis (o MyBatis Migrations para abreviar) busca:

Trabaje con cualquier base de datos, nueva o existente
Aprovechar el sistema de control de fuente (p. ej.Subversión)
Permita que los desarrolladores o equipos simultáneos trabajen de forma independiente
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
Permitir las migraciones a pesar de los privilegios de acceso o la burocracia.
Trabaja con cualquier metodología
Fomenta prácticas buenas y consistentes.

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

te lo recomiendo mucho delta de SQL.Solo lo uso para generar los scripts de diferencias cuando termino de codificar mi función y verifico esos scripts en mi herramienta de control de código fuente (Mercurial :))

Tienen una versión de servidor SQL y Oracle.

Me sorprende que nadie haya mencionado la herramienta de código abierto. liquibase que está basado en Java y debería funcionar para casi todas las bases de datos que admitan jdbc.En comparación con Rails, utiliza xml en lugar de Ruby 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 revertir ciertas operaciones como

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

Entonces no necesitas manejar esto por tu cuenta.

También se admiten declaraciones SQL puras o importaciones de datos.

La mayoría de los motores de bases de datos deberían admitir el volcado de su base de datos en un archivo.Sé que MySQL lo hace, de todos modos.Este será solo un archivo de texto, por lo que puedes enviarlo a Subversion, o lo que sea que uses.También sería fácil ejecutar una diferenciación de los archivos.

Si está utilizando SQL Server, sería difícil superar a Data Dude (también conocido como Database Edition de Visual Studio).Una vez que lo domines, hacer una comparación de esquemas entre la versión de la base de datos controlada por el código fuente y la versión en producción es muy sencillo.Y con un clic puedes generar tu DDL diferencial.

Hay una instrucción video en MSDN eso es muy útil.

Conozco DBMS_METADATA y Toad, pero si a alguien se le ocurriera un Data Dude para Oracle, la vida sería realmente agradable.

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

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

Para Oracle, uso Sapo, 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ácil de realizar 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 cómo funcionan (que se explica por sí mismo), puede escribir un script simple para volcar los resultados de esos métodos en archivos de texto que se pueden poner bajo control de código fuente.¡Buena suerte!

No estoy seguro si hay algo tan simple para MSSQL.

Escribo mis scripts de lanzamiento de base de datos en paralelo con la codificación y los guardo en una sección específica del proyecto en SS.Si hago un cambio en el código que requiere un cambio de base de datos, actualizo el script de lanzamiento al mismo tiempo.Antes del lanzamiento, ejecuto el script de lanzamiento en una base de datos de desarrollo limpia (estructura copiada de producción) y hago mis pruebas finales.

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

Sin una herramienta automatizada (vea otros comentarios aquí sobre Data Dude), utilizará scripts y archivos DDL directamente.Elija un enfoque, documentelo y sígalo rigurosamente.Me gusta tener la capacidad de recrear la base de datos en cualquier momento dado, 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). -modo de desarrollo).

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

Desde la web:

El complemento de control de versiones proporciona una estrecha integración entre el IDE de desarrollador 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

Estudio de urgencias le permite invertir el esquema de su base de datos en la herramienta y luego puede compararlo con bases de datos activas.

Ejemplo:Invierta su esquema de desarrollo en ER Studio: compárelo con la producción y enumerará todas las diferencias.Puede programar los cambios o simplemente ejecutarlos 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 envíelo a su plataforma de base de datos.

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

Puedes usar Herramientas de datos de Microsoft SQL Server en Visual Studio para generar scripts para objetos de bases de datos como parte de un proyecto de SQL Server.Luego puede agregar los scripts al control de fuente utilizando la integración de control de fuente 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 Edición de base de datos del sistema MS Team con bastante éxito.Se integra con el control de versiones de TFS y Visual Studio más o menos perfectamente y nos permite administrar fácilmente los procesos almacenados, las vistas, etc.La resolución de conflictos puede ser complicada, pero el historial de versiones se completa una vez hecho.A partir de entonces, las migraciones a control de calidad y producción son extremadamente sencillas.

Sin embargo, es justo decir que es un producto de la versión 1.0 y que 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 siguiente URL para obtener 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

A falta 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 todo el mundo lo hace y tenemos varias versiones de productos en uso, pero es mejor que nada.

Recomendaría uno de dos enfoques.Primero, invierta en Diseñador de energía 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 te permite registrar tus 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 hay en su base de datos en ese momento.Luego presentará una lista de cada diferencia y preguntará cuál debe migrarse... y luego creará el script para hacerlo.No es barato, pero es una ganga al doble de precio y su retorno de la inversión 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 de la marca de tiempo a la que movió por última vez los cambios de su base de datos en este momento, tendrá una lista ordenada de todo lo que ha hecho.Algunas cláusulas para eliminar cambios de suma cero como crear tabla foo;seguido de soltar la mesa foo;y puedes crear FÁCILMENTE un script mod.¿Por qué mantener los cambios en una wiki? Eso es el doble de trabajo.Deje que la base de datos los rastree por usted.

Dos recomendaciones de libros:"Refactorización de bases de datos" de Ambler y Sadalage y "Técnicas ágiles de bases de datos" de Ambler.

Alguien mencionó Rails Migrations.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 proceso de trasladar a Rails.Usted verifica los scripts de migración en el VCS.Aquí está una publicación del pragmático Dave Thomas sobre el tema.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow