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

votos
104

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.

Entonces, presiono el sistema en vivo y obtengo un gran error obvio de que no hay NewColumnX, uf.

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 las 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.

Publicado el 02/08/2008 a las 02:52
fuente por usuario
En otros idiomas...                            


22 respuestas

votos
56

En Ruby on Rails, hay un concepto de migración : 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 hacia arriba , ejecuta un comando llamado "db: migrate" que examina su versión y aplica los scripts necesarios. Puede migrar hacia abajo de manera similar.

Los propios scripts 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.

Respondida el 02/08/2008 a las 07:23
fuente por usuario

votos
29

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 en 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, compruebe los archivos, vuelva a probar y solicite la producción.

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

SQL

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

INSERT IGNORE  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';

Lo db_versionúnico que se cambia cuando se recrea la base de datos, y db_revisionme da una indicación de hasta qué punto 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 cortar y pegar para extraer secciones relevantes. Un poco más de limpieza está en orden, es decir, eliminar ':' de $ Revisión 1.1 $ para congelarlos.

Respondida el 26/09/2008 a las 21:29
fuente por usuario

votos
11

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

Respondida el 08/07/2011 a las 15:51
fuente por usuario

votos
11

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

Para lograr una buena práctica de gestión del cambio de base de datos, tenemos que identificar unos objetivos clave. Por lo tanto, el Sistema de MyBatis migración de esquemas (o MyBatis migraciones para abreviar) se propone:

  • Trabajar con cualquier base de datos, nueva o existente
  • Potenciar el sistema de control de fuente (por ejemplo Subversion)
  • Permitir a los desarrolladores o equipos concurrentes a trabajar de forma independiente
  • Permitir que los conflictos muy visible y fácilmente manejable
  • Permitir para avance y la migración hacia atrás (evolucionando, delegar respectivamente)
  • Hacer que el estado actual de la base de datos de fácil acceso y comprensible
  • Habilitar las migraciones a pesar de los privilegios de acceso o la burocracia
  • Trabajar con cualquier metodología
  • Anima a las buenas prácticas, consistentes
Respondida el 10/07/2010 a las 22:56
fuente por usuario

votos
10

Me pregunto que nadie menciona la herramienta de código abierto Liquibase que está basado en Java y debe trabajar para casi todas las bases de datos que soporta JDBC. En comparación con los carriles que utiliza XML en lugar de rubí 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

También se admiten las sentencias SQL puros o importación de datos.

Respondida el 10/07/2010 a las 22:26
fuente por usuario

votos
10

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

Tienen un servidor SQL y una versión de Oracle.

Respondida el 28/05/2009 a las 03:12
fuente por usuario

votos
9

La mayoría de los motores de base de datos deberían admitir 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.

Respondida el 02/08/2008 a las 02:56
fuente por usuario

votos
8

Si está usando 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 video instructivo en MSDN que es muy útil.

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

Respondida el 10/09/2008 a las 20:49
fuente por usuario

votos
7

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 funcionan (bastante explicativo), puede escribir 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.

Respondida el 01/09/2008 a las 21:57
fuente por usuario

votos
7

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 para una implementación en particular.

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

Respondida el 31/08/2008 a las 12:25
fuente por usuario

votos
7

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

Respondida el 02/08/2008 a las 07:05
fuente por usuario

votos
6

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 desarrollador PL / SQL IDE >> 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

Respondida el 17/09/2008 a las 16:50
fuente por usuario

votos
6

Lo he estado haciendo por años, gestionando (o tratando de administrar) 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 (ver otros comentarios aquí sobre Data Dude), entonces usarás 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).

Respondida el 15/09/2008 a las 16:01
fuente por usuario

votos
6

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 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.

Respondida el 30/08/2008 a las 19:58
fuente por usuario

votos
5

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 listará 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 binario de propiedad y guardarlo en control de 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.

Respondida el 17/09/2008 a las 19:04
fuente por usuario

votos
5

Hay un "framework 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 seguir los archivos fuente.

Respondida el 02/08/2008 a las 08:48
fuente por usuario

votos
3

Puede utilizar herramientas de datos de Microsoft SQL Server en Visual Studio para generar guiones para objetos de base como parte de un proyecto de SQL Server. A continuación, puede añadir las secuencias de comandos para el control de origen mediante la integración de control de origen que está integrado en Visual Studio. Además, Proyectos de SQL Server le permiten verificar los objetos de base de datos utilizando un compilador y generar scripts de implementación para actualizar una base de datos existente o crear una nueva.

Respondida el 22/12/2014 a las 11:58
fuente por usuario

votos
2

Comparación de esquemas para Oracle es una herramienta específicamente diseñada para migrar los cambios de nuestra base de datos Oracle a otra. Por favor, visite la siguiente página para encontrar el enlace de descarga, donde usted será capaz de utilizar el software para una prueba totalmente funcional.

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

Respondida el 10/01/2010 a las 03:59
fuente por usuario

votos
2

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 está exento de algunos problemas.

Respondida el 26/09/2008 a las 19:12
fuente por usuario

votos
1

Yo recomendaría uno de dos enfoques. Primero, invierta en PowerDesigner de 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.

Respondida el 26/09/2008 a las 18:53
fuente por usuario

votos
1

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ó Migraciones de Rails. 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í hay una publicación de Pragmatic Dave Thomas sobre el tema.

Respondida el 22/09/2008 a las 19:17
fuente por usuario

votos
1

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é fue cambiado. No es perfecto, ya que no todos lo hacen y tenemos varias versiones de productos en uso, pero mejor que nada.

Respondida el 01/09/2008 a las 08:29
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more