Actualizaciones de esquema de base de datos

Question

Estoy trabajando en una aplicación de AIR que usa una base de datos SQLite local y me preguntaba cómo podría administrar las actualizaciones de esquema de base de datos cuando distribuyo nuevas versiones de la aplicación. También considera actualizaciones que omiten algunas versiones. P.ej. en lugar de pasar de 1.0 a 1.1, pasando de 1.0 a 1.5.

¿Qué técnica recomendarías?

Answer 1

Nos escritura de cada cambio DDL para la base de datos y cuando hacemos una "liberación" que les concatenar en una única secuencia de comandos "actualizar", junto con los procedimientos almacenados que han cambiado "desde la última vez"

Tenemos una tabla que almacena el número de versión del último parche aplicado, por lo que las herramientas de actualización pueden aplicar parches más recientes.

Todos los procedimientos almacenados se encuentran en un archivo aparte. Cada uno comienza con una declaración de "inserción" en una tabla de registro que almacena Nombre de SProc, Versión y "ahora". (En realidad, se ejecuta un SProc para almacenar esto, no es una instrucción de inserción en bruto).

A veces, durante la implementación, cambiamos manualmente un SProc, o las probabilidades de despliegue & finalizan desde DEV, y al comparar el inicio de sesión de las bases de datos TEST y PRODUCTION del cliente nos permite verificar que todo esté en la misma versión.

También tenemos una base de datos maestra de "liberación", a la que aplicamos las actualizaciones, y utilizamos una copia de seguridad restaurada para instalaciones nuevas (ahorra tiempo de ejecución de las secuencias de comandos, que obviamente aumentan con el tiempo). Actualizamos eso como & cuando, porque obviamente si está un poco obsoleto, se pueden aplicar las últimas secuencias de comandos de parche.

Nuestra base de datos de lanzamiento también contiene datos de arranque desinfectados (que se elimina, o, a veces adoptada & modificados, antes de una nueva instalación entre en funcionamiento - por lo que no se incluye en las secuencias de comandos de actualización)

SQL Server tiene un botón de la barra de herramientas para programar un cambio, para que pueda usar las herramientas de la GUI para realizar todos los cambios, pero en lugar de guardarlos, genere un script en su lugar. (en realidad, hay una casilla de verificación para siempre generar una secuencia de comandos, por lo que si olvida y simplemente presiona GUARDAR todavía le da la secuencia de comandos que utilizó después de los hechos, que se puede guardar como el archivo de parche)

Answer 2

IMO lo más fácil es tratar una actualización de, p. 1.0 a 1.5 como una sucesión de actualizaciones de 1.0 a 1.1, 1.1 a 1.2, y así sucesivamente. Para cada cambio de versión, mantenga un script de conversión/pieza de código.

Luego, mantenga una tabla con un campo de versión en la base de datos y compile en la aplicación la versión requerida. Al inicio, si el campo de versión no coincide con la versión compilada, ejecute todos los scripts de conversión necesarios, uno por uno.

Los scripts de conversión idealmente deberían iniciar una transacción y escribir la nueva versión en la base de datos como la última declaración antes de confirmar la transacción.

Answer 3

Lo que estoy considerando es agregar una tabla SchemaVersion a la base de datos que contiene un registro para cada versión que existe. La última versión de la tabla SchemaVersion es el nivel actual de la base de datos.

Voy a crear secuencias de comandos (SQL) que llevan a cabo la configuración inicial de 1,0 y a partir de entonces la actualización de 1,0 a 1,1, 1,1 a 1,2, etc.

Incluso una nueva instalación para, por ejemplo, 1.2 se ejecutará a través de todos estos scripts. Esto puede parecer un poco lento, pero solo se realiza una vez y en una base de datos (casi) vacía.

La gran ventaja de esto es que una instalación nueva tendrá el mismo esquema de base de datos que una instalación actualizada.

Como dije: estoy considerando esto. Probablemente comenzaré a implementar esto mañana. Si estás interesado, puedo compartir mis experiencias. Implementaré esto para una aplicación C# que use LINQ-to-entities con SQL Server y MySQL como DBMSes.

Estoy interesado en escuchar las sugerencias e ideas de cualquier otra persona y si alguien puede indicarme una biblioteca .Net de código abierto o clases que implementen algo como esto, sería genial.

EDIT: En la respuesta a un question here on SO diferente encontré una referencia a Migrator.Net. Empecé a usarlo hoy y parece que es exactamente lo que estaba buscando.

Answer 4

En el caso de SQLite, puede utilizar el pragma de la versión de usuario para rastrear la versión de la base de datos. Para obtener la versión:

PRAGMA user_version 

para establecer la versión:

PRAGMA user_version = 5 

entonces sigo cada grupo de cambios en un archivo SQL (que se incrusta en la aplicación) y ejecutar las actualizaciones necesarias para levantarse a la más reciente versión:

Select Case currentUserVersion 
Case 1 
    // Upgrade to version 2 
Case 2 
    // Upgrade to version 3 
Case etc... 
End Select 

Esto permite que la aplicación se actualice a la versión más reciente, independientemente de la versión actual de la base de datos.

Answer 5

Tuve el mismo problema en una aplicación .net que estaba escribiendo.

Al final escribí mi propio marco de actualización para hacer el trabajo (no funcionará para usted porque fue escrito en C#). Es posible que desee buscar en link text para obtener algunas ideas.