design - usadas - Desarrollo ágil y cambios en la base de datos
metodologias agiles ventajas y desventajas (6)
Para esos practicantes ágiles por ahí ...
¿Cómo se gestionan los cambios en un esquema de base de datos durante un proyecto? Mi suposición es que en un proyecto ágil, el esquema de cualquier base de datos involucrada cambiará y se refactorizará tal como sucede con la base de código.
¿Es correcta esta suposición? Si es así, ¿tiene alguna herramienta o proceso en particular que use para ayudar a que las cosas funcionen sin problemas?
Eche un vistazo a las migraciones de Ruby on rails . No importa si no usa Rails, ya que la idea ya se ha copiado a otro framework.
En nuestra configuración Agile, hay una carpeta para cambios de DB, hecha como archivos .SQL. Hasta el momento hemos tenido un cambio en la base de datos en cada versión, y el nombre del archivo viene después de la versión de la aplicación. El script de instalación aplica automágicamente todos los archivos de cambio al actualizar los sitios.
También tenemos un volcado de esquema completo de un DB de referencia, que se usa para nuevas instalaciones, creado por nuestra herramienta DB Admin.
Sé que hay herramientas que ayudan a automatizar este proceso, como Red Gate, pero crear manualmente el archivo de cambio de SQL es muy fácil.
Es muy probable que la estructura de la base de datos dependa de muchas partes de su código, y los cambios de esquema tendrán efectos en cascada. Algo así como hacer cambios en la interfaz en una clase que muchas clases extienden. Así que tenga cuidado con los cambios de esquema.
La metodología ágil no es diferente de otras metodologías, ya que le conviene diseñar la base de datos por adelantado tanto como sea posible, y debe intentar cambiarla con menos frecuencia que el código. No quiere decir que nunca puedas cambiarlo, pero es costoso hacerlo.
Las migraciones son una herramienta simple pero efectiva para rastrear cambios de esquema, como otros han notado. El concepto es scripts de las sentencias CREATE y ALTER para actualizar de una revisión del esquema a la siguiente, acompañada de scripts de las sentencias ALTER y DROP para degradar los mismos cambios. Ruby on Rails utiliza una capa de abstracción de base de datos además de esto para facilitar el cambio de marcas de bases de datos, pero si solo necesita admitir una marca, simplemente podría usar archivos SQL.
Hay un libro de gran prestigio sobre este tema (aunque todavía no he llegado a comprarlo o leerlo) llamado " Refactorizar bases de datos: diseño de base de datos evolutiva " por Scott Ambler
Lo ideal sería que realice cambios sin interrupciones, y cuando se realice la liberación, puede depreciar por completo las partes antiguas del esquema. Esto no es fácil y requiere disciplina. Ni siquiera es siempre posible.
Para cada actualización, sería:
- implementar scripts de avance y retroceso,
- implementar una secuencia de comandos "compilar la base de datos desde cero",
- implementar un script de migración de datos, y
- aplicando un mecanismo por el cual el código está bloqueado a la versión de la base de datos, es decir, probando un valor que devuelve la versión actual de la base de datos, si hay una discrepancia, el sistema suelta y balbucea ruidosamente sobre la falta de coincidencia.
HTH
aclamaciones,
Robar
AgileData.org es un recurso excelente, mucho más de lo que incluyo en una sola respuesta, en el desarrollo de la Base de datos Agile. En particular, podría interesarle las Mejores prácticas de datos ágiles . Si usa SQL Server, también podría estar interesado en SQL Compare del software de Red Gate . Nuestros DBA lo han usado para ayudarme a migrar los cambios de control de calidad a producción para las aplicaciones existentes.