database - recomendaciones - porque se dañan las tablas en mysql
Actualizaciones de esquema de base de datos (5)
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. Por ejemplo, en lugar de ir de 1.0 a 1.1, pasando de 1.0 a 1.5.
¿Qué técnica recomendarías?
OMI lo más fácil es tratar una actualización de, por ejemplo, 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.
Lo ideal es que los scripts de conversión comiencen una transacción y escriban la nueva versión en la base de datos como la última declaración antes de comprometer la transacción.
Programamos cada cambio de DDL en el DB y cuando hacemos un "lanzamiento" los concatenamos en un único script de "actualización", 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 nuevos.
Todos los procedimientos almacenados están en un archivo separado. 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).
Algunas veces, durante la implementación, cambiamos manualmente un SProc o implementamos las ventajas y desventajas de DEV, y al comparar el inicio de sesión de las bases de datos TEST y PRODUCTION del cliente, podemos 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 el tiempo de ejecución de las secuencias de comandos, que obviamente aumentan con el tiempo). Actualizamos eso como y cuándo, porque obviamente si está un poco obsoleto, se pueden aplicar los scripts de parches posteriores.
Nuestra base de datos de versiones también contiene datos de inicio desinfectados (que se eliminan, o a veces se adoptan y modifican, antes de que se inicie una nueva instalación, por lo que no se incluyen en ninguna secuencia de comandos de actualización).
SQL Server tiene un botón de la barra de herramientas para realizar un script de cambio, por lo que puede 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 generar siempre una secuencia de comandos, por lo que si la olvida y solo 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 revisión)
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 ti porque fue escrito en C #). Es posible que desee buscar en el texto del enlace para obtener algunas ideas.
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 configurar la versión:
PRAGMA user_version = 5
Luego guardo cada grupo de actualizaciones en un archivo SQL (que está integrado en la aplicación) y ejecuto las actualizaciones necesarias para obtener la versión más reciente:
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 sí misma a la versión más reciente, independientemente de la versión actual de la base de datos.
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 scripts (SQL) que realicen la configuración inicial de 1.0 y, posteriormente, 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 la aplicación ac # que usa 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.
EDITAR: En la respuesta a una pregunta diferente aquí en SO , encontré una referencia a Migrator.Net. Empecé a usarlo hoy y parece que es exactamente lo que estaba buscando.