Manejo de cambios en el esquema de la base de datos cuando se envían nuevas versiones

Durante los tiempos de gran desarrollo, el esquema de la base de datos cambia tanto rápida como continuamente, y para cuando llega nuestro impulso semanal a la compilación beta, el esquema ha cambiado tanto que la única opción sensata es destruir todas las tablas que pueda y copiar las nuevas versiones de mi base de datos de desarrollo. Obviamente, esto no va a funcionar una vez que lo lancemos, ya que los datos de producción nucleares son una receta para el desastre, por lo que me preguntaba qué estrategias existían para administrar los cambios del esquema de la base de datos de una versión / revisión a otra.

Algunos que he encontrado o experimentado:

1. Nuke-and-dump directo de una base de datos a otra (lo que estoy haciendo ahora)
2. Mantener un archivo UPDATE.sql con sentencias SQL que se ejecutan a través de script o de forma manual.
3. Mantener un archivo update.php con el correspondiente valor "db-schema-version" en la base de datos activa

La tercera opción parece ser la más sensata, pero aún existe la posibilidad de que una consulta SQL mal construida falle a mitad de secuencia de comandos, dejando la base de datos en un estado medio actualizado, lo que requiere la restauración de una copia de seguridad.

Parece que no es un problema, pero sucede, ya que como equipo, usamos phpMyAdmin, y parece que ni siquiera puedo confiar en mí mismo, recuerdo haber copiado la instrucción SQL ejecutada para pegarla en el archivo update.php. Una vez que navega a otra página, tengo que volver a escribir la declaración SQL a mano, o revertir mi cambio y volver a hacerlo.

Supongo que lo que espero es una solución que no afecte nuestro flujo de trabajo de desarrollo establecido.

Automatizar. Automatizar. Automatizar.

Estás en el camino correcto con un número de versión de DB explícito, pero iría un paso más allá y haré que el código explícitamente sepa exactamente con qué esquema espera funcionar (por ejemplo, al confirmar el script DDL real y hacer que el actualizador lo analice) ); luego, en el momento de la actualización, solo tiene que descubrir el esquema existente a través de los metadatos de la base de datos e INSERT / DROP / ALTER según sea necesario, sin importar de qué versión esté actualizando. (También puede mantener un número de versión explícito en la base de datos y entregar todo el historial del esquema con el instalador para que ni siquiera necesite el descubrimiento del esquema).

Los posibles errores de sintaxis en la secuencia de comandos SQL de actualización son un problema, pero puede resolverlo verificando que el actualizador solo puede producir sentencias DDL correctas. (Las pruebas formales casi nunca valen la pena en el desarrollo de software empresarial, demasiado esfuerzo para muy poca seguridad, pero creo que la integridad de la base de datos es una de las pocas excepciones: el SQL básico no es un lenguaje particularmente difícil de capturar formalmente, y el beneficio de proteger los datos de producción es tan grande que casi cualquier cantidad de esfuerzo inicial único se justifica, especialmente si tiene que funcionar para instalaciones desatendidas)

La versión del esquema de la base de datos es el camino a seguir: cada versión solo tiene un cambio en la base de datos, o al menos cambios que se pueden revertir en su totalidad. DBDeploy es una gran herramienta para automatizar eso.

Algunas cosas que he aprendido útiles son:

1. Siempre pruebe su cambio localmente, y pruebe su código con él, solo ALTERpasar no es suficiente
2. Necesitas sincronizar qué hacer primero su cambio: una página wiki simple donde puedes "tomar un número" funcionó muy bien para mi equipo.
3. No intente arreglar el cambio roto, agregue un nuevo contra-cambio para negarlo, es muy indoloro
4. Su código depende de esos cambios: asegúrese de vincular los problemas en su sistema de seguimiento de errores con los cambios de la base de datos. Eso es muy útil en el momento de la implementación.
5. Incluya cambios de DB en su CI: aplique sus cambios a una base de datos de CI en commit. Además, si tiene alguna prueba que use una base de datos, ejecútela en commit.

Como estás usando phpMyAdmin, supongo que también estás usando MySQL.

Eche un vistazo a los diagramas del modelo EER en MySQL Workbench. Me han sido de gran ayuda para mantener y actualizar esquemas.

Primero, puede sincronizar el modelo con una fuente de base de datos. De modo que los cambios en el diagrama se envían como comandos ALTER TABLE. Esto le permite realizar los cambios de esquema en el diagrama, mantenerlo siempre actualizado y, al mismo tiempo, enviar actualizaciones a su base de datos de desarrollo cuando sea necesario.

En segundo lugar, puede realizar ingeniería inversa en un diagrama EER desde una fuente de base de datos. Lo cual puede ser útil tomando cambios en una base de datos de desarrollo y actualizando una base de datos de producción, ya que calculará las diferencias.

En tercer lugar, se puede usar para ayudar a crear el SQL que debe ir a su archivo "update.sql".

CONTRAS:

Los desencadenantes y las restricciones de la base de datos son un problema con el actualizador de sincronización. No parece saber el orden correcto de las cosas. Las restricciones de clave externa a menudo generan errores, pero esto se puede resolver editando el SQL que genera.

Esta no es una herramienta de migración de datos. Cualquier cambio que esté más allá del esquema puramente necesitará SQL personalizado.

Eche un vistazo a http://south.aeracode.org : es una biblioteca de migraciones de bases de datos para Django (un marco de Python) pero:

1. puede obtener grandes ideas de él (y tal vez incluso encontrar un clon de PHP)
2. en realidad puede usarlo independientemente del resto de Django para administrar las tablas de su aplicación PHP / MySQL.

También puede generar scripts de actualización de esquema; También maneja los cambios de inversión automáticamente la mayor parte del tiempo.