sql - versionar - ¿cuáles son los tipos de sistema control de versiones?




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

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.

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 uno. Si sucede que funciona con MS SQL Server, entonces genial.


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


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.


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.


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


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.


Lo he hecho de vez en cuando durante años, 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 "Schema Manager" (¿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).


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.


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.


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. A continuación, puede agregar los scripts al control de origen utilizando la integración de control de origen 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.


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 nueva entrada 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 cada diferencia 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 producirlos ahora, 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.


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


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 sencillo hacer una comparación de esquemas 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é sobre DBMS_METADATA y Toad, pero si alguien pudiera idear un Data Dude para Oracle, la vida sería realmente dulce.


Soy un poco de la vieja escuela, ya que uso archivos de origen 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 en project-updates.sql, por ejemplo, las declaraciones ALTER TABLE. Luego 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';

db_version solo cambia cuando se recrea la base de datos, y db_revision me da una indicación de cuán lejos está la base de datos.

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.


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.





version-control