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

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

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