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

Question

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. Realizo las modificaciones de la base de datos y continúo mi trabajo. Usualmente, recuerdo escribir los cambios para que puedan ser replicados en el sistema en vivo. Sin embargo, no siempre recuerdo lo que he cambiado y no siempre recuerdo escribirlo.

Por lo tanto, hago un push al sistema en vivo y obtengo un gran error obvio de que no hay NewColumnX, ugh.

Independientemente de que esto no sea 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 uno. Si resulta que funciona con MS SQL Server, genial.

Answer 1

En Ruby on Rails, hay un concepto de migration - una secuencia de comandos rápida para cambiar la base de datos.

Genere un archivo de migración, que tiene reglas para aumentar la versión de db (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 de db actual.

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

Las secuencias de comandos de migración se guardan en un sistema de control de versiones: cada vez que cambia la base de datos, comprueba un nuevo script y cualquier desarrollador puede aplicarlo para llevar su db local a la última versión.

Answer 2

La mayoría de los motores de base de datos deberían permitir el volcado de su base de datos en un archivo. Sé que MySQL sí, de todos modos. Esto solo será un archivo de texto, por lo que puede enviarlo a Subversion, o lo que sea que use. Sería fácil ejecutar un diff en los archivos también.

Answer 3

Para Oracle, utilizo 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 realizable en casi cualquier sistema de control de revisiones.

Answer 4

Existe un "framework de migración de base de datos" PHP5 llamado Ruckusing. No lo he usado, pero el examples muestra la idea, si usa el lenguaje para crear la base de datos cuando y cuando sea necesario, solo tiene que seguir los archivos fuente.

Answer 5

Escribo mis scripts de lanzamiento db en paralelo con la codificación, y mantengo los scripts de lanzamiento en una sección específica del proyecto en SS. Si realizo 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 db dep limpio (copiado de la estructura de producción) y hago mi prueba final en él.

Answer 6

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

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

Answer 7

En ausencia de un VCS para cambios en la tabla, los he estado registrando en una wiki. Al menos entonces puedo ver cuándo y por qué fue cambiado. No es perfecto, ya que no todos lo hacen y tenemos varias versiones de productos en uso, pero mejor que nada.

Answer 8

Eche un vistazo al paquete 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 la forma en que trabajan (bastante explicativo) que pueda escriba una secuencia de comandos simple para volcar los resultados de esos métodos en archivos de texto que pueden ponerse bajo el control de fuente. ¡Buena suerte!

No estoy seguro de si hay algo tan simple para MSSQL.

Answer 9

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 lo domine, hacer una comparación de esquema entre su versión controlada de origen de la base de datos y la versión en producción es muy fácil. Y con un clic puede generar su diff DDL.

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

Conozco DBMS_METADATA y Toad, pero si alguien pudiera encontrar un Data Dude para Oracle, entonces la vida sería muy agradable.

Answer 10

He hecho esto de forma intermitente durante años, gestionando (o intentando gestionar) las 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 esquema" (¿confunde mucho?) Que no recomiendo.

Sin una herramienta automatizada (vea otros comentarios aquí acerca de Data Dude) entonces estará usando scripts y archivos DDL directamente. Elija un enfoque, documente y siga rigurosamente. Me gusta tener la capacidad de volver a crear la base de datos en cualquier momento dado, así 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).

Answer 11

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

De la web:

la versión de control de plug-in ofrece una estrecha integración entre el IDE desarrollador PL/SQL >> y cualquier sistema de control de versiones que soporta la especificación de interfaz de Microsoft SCC. >> 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

Answer 12

ER Studio le permite invertir el esquema de base de datos en la herramienta y se puede luego compararla con las bases de datos en vivo.

Ejemplo: Invierta su esquema de desarrollo en ER Studio - compárelo con la producción y enumerará todas las diferencias. Puede guiar los cambios o simplemente presionarlos automáticamente.

Una vez que tenga un esquema en ER Studio, puede guardar el script de creación o guardarlo como un archivo binario de propiedad y guardarlo en el control de la versión. Si alguna vez quiere volver a una versión anterior del esquema, simplemente échele un vistazo y empújelo a su plataforma de db.

Answer 13

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

Alguien mencionó Rails Migrations. Creo que funcionan muy bien, incluso fuera de las aplicaciones de Rails. Los usé en una aplicación ASP con SQL Server que estábamos en proceso de mover a Rails. Usted verifica los propios guiones de migración en el VCS. Aquí está a post by Pragmatic Dave Thomas sobre el tema.

Answer 14

Recomendaría uno de los dos enfoques. Primero, invierta en PowerDesigner desde Sybase. Edición de Empresa. Le permite diseñar modos de datos Físicos, y mucho más. Pero viene con un repositorio que te permite verificar tus modelos. Cada nueva verificación 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. A continuación, presentará una lista de cada diferencia y preguntará qué se debe migrar ... y luego construye 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 de la marca de tiempo que modificó por última vez los cambios en su base de datos para solicitar ahora, tendrá una lista ordenada de todo lo que ha hecho. Unas pocas cláusulas para eliminar cambios de suma cero como create table foo; seguido de drop table foo; y puedes construir FÁCILMENTE un script MOD. Por qué mantener los cambios en una wiki, eso duplica el trabajo. Deje que la base de datos los rastree por usted.

Answer 15

Hemos utilizado MS Team System Database Edition con bastante éxito. Se integra con el control de versiones TFS y Visual Studio más o menos a la perfección y nos permite administrar procesos almacenados, vistas, etc., fácilmente. La resolución de conflictos puede ser un problema, pero el historial de versiones se completa una vez que está hecho. A partir de entonces, las migraciones a QA y la producción son extremadamente simples.

Es justo decir que es un producto de la versión 1.0, sin embargo, y no sin algunos problemas.

Answer 16

Soy un poco viejo en la 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 el control de la 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 ALTER TABLE. Luego puedo aplicar las actualizaciones a la base de datos de desarrollo, probar, iterar hasta que se haga bien. Luego, ingrese los archivos, vuelva a probar y aplique a la producción.

Además, por lo general tienen una mesa en el PP - Config - tales 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: $'); 

Entonces, puedo añadir lo siguiente a la sección de actualización:

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

El db_version solo cambia cuando se recrea la base de datos, y el db_revision me da una indicación de la distancia el DB está fuera de la línea de base.

Pude guardar las actualizaciones en sus propios archivos separados, pero elegí mezclarlos todos juntos y usar el corte & para extraer secciones relevantes. Se necesita un poco más de limpieza, es decir, eliminar ':' de $ Revisión 1.1 $ para congelarlos.

Answer 17

Recomiendo encarecidamente SQL delta. Solo lo uso para generar las secuencias de comandos diff cuando terminé de codificar mi función y verificar esas secuencias de comandos en mi herramienta de control de origen (Mercurial :))

Tienen un servidor SQL & versión de Oracle.

Answer 18

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

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

Answer 19

Me pregunto que nadie menciona la herramienta de código abierto liquibase que es basado en Java y debe trabajar para casi todas las bases de datos que soporta JDBC. En comparación con los rieles, utiliza xml en lugar de ruby ​​para realizar los cambios de esquema. Aunque me gusta XML para lenguajes específicos de dominio la ventaja muy fresco del XML es que Liquibase sabe cómo restituir ciertas operaciones como

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

Así que no es necesario para manejar esto de su propia

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

Answer 20

MyBatis (anteriormente iBatis) tiene una herramienta schema migration, para usar en la línea de comandos. Está escrito en java aunque se puede usar con cualquier proyecto.

Para lograr una buena práctica de gestión de cambio de base de datos, necesitamos identificar algunos objetivos clave. Por lo tanto, el Sistema de Migración MyBatis esquema (o MyBatis migraciones para abreviar) busca:

• Trabaja con cualquier base de datos, nueva o existente
• aprovechar el sistema de control de fuente (por ejemplo,La subversión)
• permiten a los desarrolladores o equipos concurrentes a trabajar de forma independiente
• permitir que los conflictos muy visible y fácilmente manejable
• Permitir hacia adelante y la migración hacia atrás (evolucionando, delegar respectivamente)
• Hacer el estado actual de la base de datos de fácil acceso y comprensible
• Habilitar migraciones a pesar de los privilegios de acceso o la burocracia
• Trabaja con cualquier metodología
• Alienta buenas prácticas, consistentes

Answer 21

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

Answer 22

Puede usar Microsoft SQL Server Data Tools en Visual Studio para generar scripts para objetos de base de datos como parte de un proyecto de SQL Server. A continuación, puede agregar los scripts al control de fuente utilizando la integración de control de fuente que está incorporada 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.