¿Cómo se hace un seguimiento decente de la modificación de la estructura de la database por SVN?

El problema principal es la versión de la estructura de la database.

Las utilidades estándar mysqldump y pg_dump no producen files muy adecuados para el control de versiones.

Los commands de volcado generan los files de volcado con valores de autoincrement, inputs de TOC, etc. Dado que estos objects están sujetos a cambios continuos, siempre produce los files de gran diferencia.

PostgreSQL Diff

-- --- TOC entry 2630 (class 0 OID 0) +-- TOC entry 2549 (class 0 OID 0) -- Dependencies: 6 -- Name: SCHEMA adm; Type: COMMENT; Schema: -; Owner: admin @@ -61,5 +61,5 @@ 

MySQL Diff

 --- Dump completed on 2010-07-20 14:33:44 +-- Dump completed on 2010-08-11 8:59:39 Index: /db.sql =================================================================== --- /db.sql (revision 1274) +++ /db.sql (revision 1317) @@ -36,5 +36,5 @@ `message` text, PRIMARY KEY (`id`) -) ENGINE=MyISAM AUTO_INCREMENT=21122 DEFAULT CHARSET=utf8; +) ENGINE=MyISAM AUTO_INCREMENT=23730 DEFAULT CHARSET=utf8; 

Cualquier sugerencia / enlaces / utilidades en una mejor forma de control de versión son apreciadas!

Gracias.

Eche un vistazo a LiquiBase ( http://www.liquibase.org/ )

Es una herramienta diseñada para permitir a los desarrolladores realizar cambios en la database a SVN y luego aplicarlos de manera segura y automática a la database.

Los cambios pueden ser de ingeniería inversa mediante la comparación de dos bases de datos, o codificados a mano por el desarrollador y comprometidos.

También garantiza que los cambios en la database se apliquen en el order correcto y solo se apliquen una vez a una database determinada.

Simplemente versionamos los scripts utilizados para crear la database desde cero. Los desarrolladores editan los scripts en los files de text, y no en la database. Los desarrolladores no tienen acceso a los serveres de SQL de producción, y el equipo de DBA utiliza herramientas específicamente diseñadas para comparar esquemas de bases de datos (en nuestro caso, Red-Gate SQLCompare) para realizar comstackciones de producción. Crearán una nueva database vacía desde los scripts y usarán la herramienta de comparación para detectar cambios. Algunos cambios se pueden aplicar automáticamente, y algunos se deben modificar manualmente.

No es un sistema perfecto, pero hasta ahora nos ha funcionado bastante bien.

No utilizaría los volcados de MySQL porque se usan principalmente para hacer copys de security de datos, y generalmente no usa el control de versiones para administrar copys de security de datos. En cambio, solo controlaría la versión del script de installation o el file SQL utilizado para configurar la estructura de la database inicial.

Para proyectos pequeños, generalmente solo tengo un file llamado install.sql que contiene todas mis instrucciones CREATE y schema.txt que describe el esquema. Para proyectos más grandes, es posible que desee utilizar algo como dbForge, que permite versiones de esquema de database en la edición profesional, aunque es un poco caro si eso es todo lo que está utilizando.

Consulte este artículo sobre Codificación de terror (especialmente el primer enlace en esa publicación) para get más información.

Recientemente, Depesz escribió una publicación en un blog sobre " ¿CÓMO ADMINISTRAR CAMBIOS A SU BASE DE DATOS? "

Yo diría que:

  • Si simplemente almacena el esquema de cada object en SVN, aún necesita implementar cambios orderando dependencies y modificaciones de datos, de modo que todo lo que realmente le compra en sí mismo es categorizar su historial de cambios en los objects involucrados.
  • Escriba scripts para realizar todos los cambios, incluidos los scripts para deshacer los cambios.
  • Utilice apgdiff para producir diferencias de esquema de database (PostgreSQL).

Puede usar otra herramienta PostgreSQL Diff Tool para bases de datos PostgreSQL para comparar su esquema de desarrollo y esquema de producción. Simplemente actualice su database de desarrollo de la forma más cómoda para hacerlo. Cuando desee actualizar la database de producción al estado de la database de desarrollo, descargue los esquemas de la database de desarrollo y los esquemas de la database de producción y permita que apgdiff los compare. Le producirá resultados que contienen sentencias DDL necesarias para transformar su database de producción al estado de la database de desarrollo.

De hecho, depende de usted cómo implementar apgdiff en su ciclo de desarrollo, todo lo que hace es generar resultados con sentencias DDL para "mover" su database de producción al mismo estado que la database de desarrollo.

En el website puede encontrar información sobre cómo funciona, cómo usarlo, qué afirmaciones son compatibles, etc. También hay un artículo sobre la actualización del esquema de PostgreSQL en mi blog en http://www.fordfrog.name (se me permitió include solo un enlace para no pudo hacer este enlace de dirección también).