¿Cuáles son las mejores prácticas para scripts de bases de datos bajo control de código

Question

Actualmente estamos revisando cómo almacenamos nuestros scripts de base de datos (tablas, procesos, funciones, vistas, arreglos de datos) en subversión y me preguntaba si hay consenso sobre qué es el mejor enfoque?

Algunos de los factores que tendríamos que tener en cuenta son:

• En caso de que el check-in 'Crear' scripts o cambios incrementales registro con scripts 'Alter'
• ¿Cómo podemos mantener un registro del estado de la base de datos para un lanzamiento dado
• Debe ser fácil construir una base de datos desde cero para cualquier versión de lanzamiento dada
• Debe existir una tabla en la base de datos que enumere los scripts que se han ejecutado, o la versión de la base de datos, etc.

Obviamente, es una pregunta bastante abierta, por lo que estoy ansioso por escuchar lo que la experiencia de la gente les ha enseñado.

Answer 1

La opción de crear la escritura:

Uso crear scripts que se genera la versión más reciente de la base de datos desde cero, que está vacía, excepto los datos de búsqueda por defecto.

Utilice las técnicas de control de versiones estándar para almacenar, ramificar, etiquetar versiones y ver historias de sus objetos.

Al actualizar una base de datos en vivo (en el que no quiere perder datos), crear una segunda copia en blanco de la base de datos a la nueva versión y utilizar una herramienta como link text

Pros de color rojo-gate: Cambios a los archivos se realiza un seguimiento en una fuente de código estándar de la misma manera

Contras: la dependencia del uso manual de una herramienta de tercera parte para hacer mejoras reales (no/poco automatización)

Answer 2

Usted podría conseguir algunas pistas mediante la lectura de cómo esto se hace con Ruby On Rails' migrations. La mejor manera de entender esto es probarlo usted mismo y luego inspeccionar manualmente la base de datos.

Las respuestas a cada uno de sus factores:

• tienda crear secuencias de comandos. Si desea ejecutar la versión x.y.z, sería bueno simplemente ejecutar su script de creación para configurar la base de datos inmediatamente. Usted podría agregar secuencias de comandos ALTER para pasar de la versión anterior a la siguiente (p. Ej., Confirma la versión 3 que contiene una secuencia de comandos CREATE de la versión 3 y una secuencia de comandos de la versión 2 → 3).
• Consulte la solución de migración de Rails. Básicamente mantienen el número de versión de la tabla en la base de datos, para que siempre lo sepas.
• Usar scripts CREATE.
• El uso de números de versión probablemente sea la solución más genérica — los nombres de los scripts y las rutas pueden cambiar con el tiempo.

Mis dos centavos!

Answer 3

La opción de comandos de actualización

tienda cada cambio en la base de datos como una secuencia de comandos SQL separada. Almacene cada grupo de cambios en una carpeta numerada. Utilice una secuencia de comandos para aplicar cambios a una carpeta a la vez y registrar en la base de datos qué carpetas se han aplicado.

Pros: , ruta de actualización comprobable totalmente automatizado

Contras: Difícil de ver el historial completo de cada elemento individual tiene que construir una nueva base de datos a partir de cero, pasando por todas las versiones

Answer 4

tiendo para verificar en el script de creación inicial. Luego tengo una tabla DbVersion en mi base de datos y mi código usa eso para actualizar la base de datos en la conexión inicial si es necesario. Por ejemplo, si mi base de datos está en la versión 1 y mi código está en la versión 3, mi código aplicará las sentencias ALTER para llevarlo a la versión 2, luego a la versión 3. Utilizo una declaración simple de conmutación fallida para esto.

Esto tiene la ventaja de que cuando implemente una nueva versión de su aplicación, actualizará automáticamente las viejas bases de datos y nunca tendrá que preocuparse de que la base de datos no esté sincronizada con el software. También mantiene un historial de cambios muy visible.

Esto no es una buena idea para todo el software, pero se pueden aplicar variaciones.

Answer 5

Nuestra empresa los comprueba simplemente porque alguien decidió ponerlo en algún documento de SOX que hagamos. No tiene ningún sentido para mí, excepto posible como documento de referencia. No veo la hora en que los saquemos y tratemos de usarlos de nuevo, y si lo hiciéramos, tendríamos que saber cuál corrió primero y cuál para ejecutar después de eso. Copia de seguridad de la base de datos es mucho más importante que mantener los scripts Alter.

Answer 6

Después de unas pocas iteraciones, el enfoque que tomamos fue más o menos así:

Un archivo por mesa y por procedimiento almacenado. También separe los archivos para otras cosas como configurar usuarios de la base de datos, rellenar tablas de búsqueda con sus datos.

El archivo de una tabla comienza con el comando CREAR y se agrega una sucesión de comandos ALTER a medida que el esquema evoluciona. Cada uno de estos comandos está entre corchetes en las pruebas de si la tabla o columna ya existe. Esto significa que cada script se puede ejecutar en una base de datos actualizada y no cambiará nada. También significa que para cualquier base de datos anterior, el script lo actualiza al último esquema. Y para una base de datos vacía, el script CREATE crea la tabla y todos los scripts ALTER son omitidos.

También tenemos un programa (escrito en Python) que escanea el directorio lleno de scripts y los ensambla en un script grande. Analiza el SQL lo suficiente como para deducir las dependencias entre las tablas (en función de las referencias de clave externa) y ordenarlas de forma adecuada. El resultado es una secuencia de comandos SQL monstruosa que hace que la base de datos cumpla con las especificaciones de una vez. El programa de ensamblaje de scripts también calcula el hash MD5 de los archivos de entrada y lo utiliza para actualizar un número de versión que está escrito en una tabla especial en el último script de la lista.

Al no tener accidentes, el resultado es que el script de la base de datos para una versión de entrega del código fuente crea el esquema con el que este código fue diseñado para interoperar. También significa que hay un solo script SQL (algo grande) para entregar al cliente para construir nuevas bases de datos o actualizar las existentes. (Esto fue importante en este caso porque habría muchas instancias de la base de datos, una para cada uno de sus clientes).)

Answer 7

Hay un interesante artículo en el siguiente enlace: http://www.codinghorror.com/blog/archives/001050.html

Se aboga por una línea de base 'crear' guión seguido por el control de secuencias de comandos 'alter' y mantener una tabla de versión en la base de datos.

Answer 8

para cada versión necesitamos dar un archivo update.sql que contenga todos los nuevos scripts de tabla, declaraciones de modificación, paquetes nuevos/modificados, roles, etc. Este archivo se utiliza para actualizar la base de datos de 1 versión a 2.

Lo que siempre incluimos en el archivo update.sql de arriba uno de estas declaraciones debe ir a archivos respectivos individuales. Al igual que la declaración alternativa tiene que ir a la tabla como una nueva columna (la secuencia de comandos de la tabla debe modificarse no se agrega después de crear la secuencia de comandos de la tabla en el archivo) de la misma manera nuevas tablas, roles, etc.

Así que siempre que sea usuario quiere actualizar usará el primer archivo update.sql para actualizar. Si quiere construir desde scrach, usará build.sql, que ya tiene todas las declaraciones anteriores, hace que la base de datos esté sincronizada.

Sriramulu Sriramis4u@yahoo.com

Answer 9

Creamos una sucursal en Subversion y todos los cambios de base de datos para la próxima versión son secuencias de comandos y registramos. Todos los guiones son repetibles para que pueda ejecutar varias veces sin ellas error.

También vinculamos los scripts de cambios para emitir elementos o identificadores de errores para que podamos contener un conjunto de cambios si es necesario. Luego tenemos un proceso de compilación automatizado que analiza los elementos de problema que estamos lanzando y extrae los scripts de cambio de Subversion y crea un solo archivo de script SQL con todos los cambios ordenados de manera apropiada.

Este archivo único se utiliza para promocionar los cambios en los entornos de Prueba, QA y Producción. El proceso de compilación automatizada también crea entradas de la base de datos que documentan la versión (rama más ID de compilación). Creemos que este es el mejor enfoque con los desarrolladores de empresas. Más detalles sobre la forma en que hacemos esto se pueden encontrar HERE

Answer 10

En mi caso, voy a construir un guión SH para este trabajo: https://github.com/reduardo7/db-version-updater

Answer 11

Hay un interesante artículo con el nuevo sitio de red https://blog.codinghorror.com/get-your-database-under-version-control/

Es una un poco viejo, pero los conceptos todavía están allí. ¡Buena lectura!