Mecanismos para el seguimiento de cambios en el esquema de DB

votos
128

¿Cuáles son los mejores métodos para rastrear y / o automatizar los cambios al esquema DB? Nuestro equipo usa Subversion para el control de versiones y hemos podido automatizar algunas de nuestras tareas de esta manera (llevando las compilaciones a un servidor de etapas, implementando el código probado en un servidor de producción) pero aún estamos haciendo actualizaciones de base de datos manualmente. Me gustaría encontrar o crear una solución que nos permita trabajar eficientemente en servidores con diferentes entornos mientras continuamos utilizando Subversion como back-end a través del cual el código y las actualizaciones de bases de datos se envían a varios servidores.

Muchos paquetes de software populares incluyen scripts de actualización automática que detectan la versión de DB y aplican los cambios necesarios. ¿Es esta la mejor manera de hacerlo incluso a una escala mayor (en múltiples proyectos y, a veces, en múltiples entornos e idiomas)? Si es así, ¿existe algún código que simplifique el proceso o es mejor rodar nuestra propia solución? ¿Alguien ha implementado algo similar antes y lo ha integrado a los ganchos post-commit de Subversion, o es una mala idea?

Si bien es preferible una solución que admita múltiples plataformas, definitivamente necesitamos admitir la pila Linux / Apache / MySQL / PHP ya que la mayoría de nuestro trabajo está en esa plataforma.

Publicado el 04/08/2008 a las 22:31
fuente por usuario
En otros idiomas...                            


20 respuestas

votos
5

Es un poco de baja tecnología, y podría haber una mejor solución, pero podrías simplemente almacenar tu esquema en un script SQL que se puede ejecutar para crear la base de datos. Creo que puedes ejecutar un comando para generar este script, pero desafortunadamente no conozco el comando.

Luego, ingrese la secuencia de comandos en control de fuente junto con el código que funciona en ella. Cuando necesite cambiar el esquema junto con el código, el script puede registrarse junto con el código que requiere el esquema modificado. Entonces, los diffs en la secuencia de comandos indicará diffs en los cambios de esquema.

Con este script, podrías integrarlo con DBUnit o algún tipo de script de compilación, por lo que parece que podría encajar con tus procesos ya automatizados.

Respondida el 04/08/2008 a las 23:28
fuente por usuario

votos
54

En el mundo de Rails, existe el concepto de migraciones, scripts en los que los cambios en la base de datos se realizan en Ruby en lugar de un sabor de SQL específico de la base de datos. Su código de migración de Ruby termina convirtiéndose en el DDL específico de su base de datos actual; esto hace que cambiar de plataforma de base de datos sea muy fácil.

Por cada cambio que realice en la base de datos, usted escribe una nueva migración. Las migraciones suelen tener dos métodos: un método "arriba" en el que se aplican los cambios y un método "abajo" en el que se deshacen los cambios. Un solo comando actualiza la base de datos y también puede usarse para llevar la base de datos a una versión específica del esquema. En Rails, las migraciones se mantienen en su propio directorio en el directorio del proyecto y se controlan en el control de la versión como cualquier otro código de proyecto.

Esta guía de Oracle para las migraciones de Rails cubre las migraciones bastante bien.

Los desarrolladores que usan otros lenguajes han observado las migraciones y han implementado sus propias versiones específicas del idioma. Sé de Ruckusing , un sistema de migraciones PHP que se modela después de las migraciones de Rails; puede ser lo que estás buscando.

Respondida el 04/08/2008 a las 23:45
fuente por usuario

votos
5

Si está utilizando C #, eche un vistazo a Subsonic, una herramienta ORM muy útil, pero también genera un script sql para recrear su esquema y / o datos. Estos scripts pueden ponerse en control de fuente.

http://subsonicproject.com/

Respondida el 04/08/2008 a las 23:47
fuente por usuario

votos
3

Creo carpetas con el nombre de las versiones de compilación y coloco scripts de actualización y degradación allí. Por ejemplo, podría tener las siguientes carpetas: 1.0.0, 1.0.1 y 1.0.2. Cada uno contiene el script que le permite actualizar o degradar su base de datos entre versiones.

Si un cliente o cliente lo llama con un problema con la versión 1.0.1 y está utilizando 1.0.2, volver a poner la base de datos en su versión no será un problema.

En su base de datos, cree una tabla llamada "esquema" donde coloca la versión actual de la base de datos. Entonces, escribir un programa que pueda actualizar o degradar su base de datos es fácil.

Como dijo Joey, si estás en un mundo de Rails, usa Migraciones. :)

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

votos
11

Mi equipo codifica todos los cambios de la base de datos y los envía a SVN junto con cada versión de la aplicación. Esto permite cambios incrementales de la base de datos, sin perder ningún dato.

Para ir de una publicación a la siguiente, solo necesita ejecutar el conjunto de scripts de cambios, y su base de datos está actualizada, y todavía tiene todos sus datos. Puede que no sea el método más fácil, pero definitivamente es efectivo.

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

votos
6

Vuelque su esquema en un archivo y agréguelo al control de fuente. Entonces, una simple diferencia le mostrará qué cambió.

Respondida el 06/08/2008 a las 17:59
fuente por usuario

votos
4

Usamos una solución muy simple pero efectiva.

Para instalaciones nuevas, tenemos un archivo metadata.sql en el repositorio que contiene todo el esquema DB, luego en el proceso de compilación usamos este archivo para generar la base de datos.

Para las actualizaciones, agregamos las actualizaciones en el software codificadas. Lo mantenemos codificado porque no nos gusta resolver problemas antes de que realmente sea un problema, y ​​este tipo de cosas no resultó ser un problema hasta el momento.

Entonces en nuestro software tenemos algo como esto:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Este código verificará si la base de datos está en la versión 1 (que está almacenada en una tabla creada automáticamente), si está desactualizada, entonces se ejecuta el comando.

Para actualizar metadata.sql en el repositorio, ejecutamos estas actualizaciones localmente y luego extraemos los metadatos completos de la base de datos.

Lo único que ocurre cada cierto tiempo es olvidar el metadata.sql, pero este no es un problema importante porque es fácil de probar en el proceso de compilación y también lo único que podría suceder es hacer una nueva instalación con una base de datos obsoleta y la actualizó en el primer uso.

Además, no admitimos las degradaciones, pero es por diseño, si algo se rompe en una actualización, restauramos la versión anterior y reparamos la actualización antes de volver a intentarlo.

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

votos
4

Utilicé la siguiente estructura de proyecto de base de datos en Visual Studio para varios proyectos y funcionó bastante bien:

Base de datos

Cambiar guiones

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Crear guiones

Sprocs

Funciones

Puntos de vista

Nuestro sistema de compilación luego actualiza la base de datos de una versión a la siguiente ejecutando los guiones en el siguiente orden:

1.PreDeploy.sql

2.SchemaChanges.sql

Contenido de la carpeta Create Scripts

2.DataChanges.sql

3.Permissions.sql

Cada desarrollador verifica sus cambios para un error / característica en particular al agregar su código al final de cada archivo. Una vez que una versión principal está completa y ramificada en control de fuente, los contenidos de los archivos .sql en la carpeta Cambiar Scripts se eliminan.

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

votos
48

Usamos algo similar a bcwoord para mantener nuestros esquemas de base de datos sincronizados en 5 instalaciones diferentes (producción, puesta en escena y algunas instalaciones de desarrollo) y una copia de seguridad en el control de versiones, y funciona bastante bien. Voy a elaborar un poco:


Para sincronizar la estructura de la base de datos, tenemos una única secuencia de comandos, update.php y una serie de archivos numerados 1.sql, 2.sql, 3.sql, etc. La secuencia de comandos usa una tabla adicional para almacenar el número de versión actual de la base de datos. Los archivos N.sql están hechos a mano, para pasar de la versión (N-1) a la versión N de la base de datos.

Se pueden usar para agregar tablas, agregar columnas, migrar datos de un formato de columna antiguo a uno nuevo, luego colocar la columna, insertar filas de datos "maestras" como tipos de usuario, etc. Básicamente, puede hacer cualquier cosa, y con los datos adecuados scripts de migración nunca perderá datos.

El script de actualización funciona así:

  • Conéctese a la base de datos.
  • Haga una copia de seguridad de la base de datos actual (porque las cosas saldrán mal) [mysqldump].
  • Crear una tabla de contabilidad (llamada _meta) si no existe.
  • Lee la VERSIÓN actual de la tabla _meta. Suponga 0 si no se encuentra.
  • Para todos los archivos .sql numerados más arriba que VERSIÓN, ejecútelos en orden
  • Si uno de los archivos produjo un error: retroceda a la copia de seguridad
  • De lo contrario, actualice la versión en la tabla de contabilidad al archivo .sql más alto ejecutado.

Todo entra en control de la fuente, y cada instalación tiene una secuencia de comandos para actualizar a la última versión con una sola ejecución de scripts (llamando a update.php con la contraseña adecuada de la base de datos, etc.). Nosotros SVN actualizamos los entornos de producción y producción a través de un script que llama automáticamente al script de actualización de la base de datos, por lo que una actualización de código incluye las actualizaciones de base de datos necesarias.

También podemos usar la misma secuencia de comandos para recrear toda la base de datos desde cero; simplemente dejamos caer y recreamos la base de datos, luego ejecutamos la secuencia de comandos que repoblará completamente la base de datos. También podemos usar la secuencia de comandos para llenar una base de datos vacía para realizar pruebas automatizadas.


Tomó solo unas pocas horas configurar este sistema, es conceptualmente simple y todos obtienen el esquema de numeración de la versión, y ha sido invaluable al tener la capacidad de avanzar y desarrollar el diseño de la base de datos, sin tener que comunicarse o ejecutar manualmente las modificaciones en todas las bases de datos

Sin embargo, tenga cuidado al pegar consultas de phpMyAdmin. Esas consultas generadas generalmente incluyen el nombre de la base de datos, que definitivamente no desea, ya que romperá sus scripts. Algo así como CREATE TABLE mydb. newtable(...) fallará si la base de datos en el sistema no se llama mydb. Creamos un enlace de SVN previo al comentario que no permitirá archivos .sql que contengan la mydbcadena, que es una señal segura de que alguien copió / pegó desde phpMyAdmin sin una comprobación adecuada.

Respondida el 22/08/2008 a las 15:44
fuente por usuario

votos
2

Para mi proyecto actual de PHP usamos la idea de migraciones de rieles y tenemos un directorio de migraciones en el cual guardamos el título de los archivos "migration_XX.sql" donde XX es el número de la migración. Actualmente, estos archivos se crean a mano a medida que se realizan las actualizaciones, pero su creación podría modificarse fácilmente.

Luego tenemos un script llamado "Migration_watcher" que, como estamos en pre-alpha, actualmente se ejecuta en cada carga de página y verifica si hay un nuevo archivo migration_XX.sql donde XX es más grande que la versión de migración actual. Si es así, ejecuta todos los archivos migration_XX.sql hasta el número más grande contra la base de datos y ¡listo! los cambios de esquema están automatizados.

Si necesita la capacidad de revertir el sistema, se necesitarían muchos ajustes, pero es simple y ha funcionado muy bien para nuestro pequeño equipo hasta el momento.

Respondida el 23/08/2008 a las 13:58
fuente por usuario

votos
6

Scott Ambler produce una gran serie de artículos (y es coautor de un libro ) sobre la refacturación de bases de datos, con la idea de que esencialmente debe aplicar los principios y prácticas de TDD para mantener su esquema. Configura una serie de pruebas de estructura y de unidad de datos de inicialización para la base de datos. Luego, antes de cambiar algo, modifica / escribe pruebas para reflejar ese cambio.

Hemos estado haciendo esto por un tiempo y parece funcionar. Escribimos código para generar el nombre de columna básico y las comprobaciones de tipo de datos en un conjunto de pruebas unitarias. Podemos volver a ejecutar esas pruebas en cualquier momento para verificar que la base de datos en la verificación de SVN coincida con la versión en vivo de la aplicación que se está ejecutando realmente.

Como resultado, los desarrolladores también a veces modifican su base de datos sandbox y olvidan actualizar el archivo de esquema en SVN. El código depende de un cambio de db que no haya sido registrado. Ese tipo de error puede ser extremadamente difícil de precisar, pero el banco de pruebas lo recogerá de inmediato. Esto es particularmente bueno si lo tiene integrado en un plan de integración continua más grande.

Respondida el 29/08/2008 a las 05:51
fuente por usuario

votos
5

K. Scott Allen tiene uno o dos artículos decentes sobre el control de versiones de esquemas, que usa el concepto incremental de scripts / migraciones de actualización al que se hace referencia en otras respuestas aquí; ver http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Respondida el 29/08/2008 a las 06:11
fuente por usuario

votos
2

Recomendaría usar Ant (multiplataforma) para el lado del "guión" (ya que prácticamente puede hablar con cualquier db que exista a través de jdbc) y Subversion para el repositorio de origen. Ant le permitirá "hacer una copia de seguridad" de su base de datos en archivos locales, antes de realizar cambios. 1. Haga una copia de seguridad del esquema de base de datos existente en el archivo a través del control de versiones de Ant 2. en el repositorio de Subversion a través de Ant 3. envíe nuevas instrucciones sql a db a través de Ant.

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

votos
9

El problema aquí es realmente facilitar a los desarrolladores el script de sus propios cambios locales en el control de fuente para compartir con el equipo. Me he enfrentado a este problema durante muchos años y me inspiré en la funcionalidad de los profesionales de Visual Studio for Database. Si desea una herramienta de código abierto con las mismas características, intente esto: http://dbsourcetools.codeplex.com/ Diviértase, - Nathan.

Respondida el 07/07/2009 a las 14:26
fuente por usuario

votos
0

Existe una herramienta de línea de comandos mysql-diff que compara esquemas de bases de datos, donde el esquema puede ser una base de datos en vivo o un script SQL en el disco. Es bueno para la mayoría de las tareas de migración de esquema.

Respondida el 04/11/2009 a las 20:43
fuente por usuario

votos
9

Si aún están buscando soluciones: estamos proponiendo una herramienta llamada diseñador Nextep. Es un entorno de desarrollo de base de datos con la que se puede poner toda su base de datos bajo control de versiones. Se trabaja en un repositorio de control de versiones, donde cada cambio puede ser rastreado.

Cuando tenga que lanzar una actualización, puede comprometer sus componentes y el producto va a generar automáticamente el script de actualización SQL de la versión anterior. Por supuesto, se puede generar este SQL desde cualquier 2 versiones.

A continuación, usted tiene muchas opciones: se puede tomar esos guiones y ponerlos en su SVN con su código de aplicación para que va a ser desplegado por el mecanismo existente. Otra opción es utilizar el mecanismo de entrega de Nextep: guiones se exportan en algo que se llama un "paquete de entrega" (scripts SQL + descriptor XML), y un instalador puede entender este paquete y desplegarlo a un servidor de destino al tiempo que garantiza la consistencia strcutural, la dependencia comprobar, registrando versión instalada, etc.

El producto es GPL y está basado en Eclipse para que se ejecute en Linux, Mac y Windows. También soporta Oracle, MySQL y PostgreSQL en el momento (el soporte de DB2 está en camino). Echar un vistazo a la wiki donde encontrará información más detallada: http://www.nextep-softwares.com/wiki

Respondida el 25/10/2010 a las 06:46
fuente por usuario

votos
2

Toad for MySQL tiene una función llamada comparación de esquemas que le permite sincronizar 2 bases de datos. Es la mejor herramienta que he utilizado hasta ahora.

Respondida el 05/02/2011 a las 12:08
fuente por usuario

votos
2

migraciones en mi humilde opinión tiene un gran problema:

La actualización de una versión a otra funciona bien, pero haciendo una nueva instalación de una versión determinada podrían tener para siempre si tiene cientos de mesas y un largo historial de cambios (como nosotros).

Ejecución de toda la historia de los deltas desde la línea de base hasta la versión actual (por cientos de bases de datos de clientes) podría tomar un tiempo muy largo.

Respondida el 12/03/2011 a las 15:15
fuente por usuario

votos
2

Me gusta la manera cómo Yii maneja las migraciones de bases de datos. Una migración es básicamente un script PHP implementación CDbMigration. CDbMigrationdefine un upmétodo que contiene la lógica de la migración. También es posible implementar un downmétodo para apoyar la inversión de la migración. Como alternativa, safeUpo safeDownse puede utilizar para asegurarse de que la migración se realiza en el contexto de una transacción.

Herramienta de línea de comandos de yü yiiccontiene soporte para crear y ejecutar migraciones. Las migraciones se pueden aplicar o invertidas, ya sea uno por uno o en un lote. La creación de una migración resultados en código para la implementación de una clase PHP CDbMigration, con un nombre único basado en una marca de tiempo y un nombre de migración especificado por el usuario. Todas las migraciones que se han aplicado con anterioridad a la base de datos se almacenan en una tabla de migración.

Para obtener más información, consulte la migración de base de datos artículo del manual.

Respondida el 25/06/2011 a las 14:18
fuente por usuario

votos
2

Tratar de implementar db - principalmente una herramienta de Java, pero funciona con php también.

Respondida el 19/01/2012 a las 02:52
fuente por usuario

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