ver restoring recuperacion estado datos sql database architecture schema methodology

sql - restoring - Mejores metodologías de control de cambio de base de datos



base de datos en estado restoring sql server (5)

Como arquitecto, desarrollador y consultor de bases de datos, hay muchas preguntas que pueden ser respondidas. Uno, aunque me preguntaron recientemente y todavía no puedo responder bien, es ...

"¿Cuál es uno de los mejores métodos o técnicas para mantener los cambios en la base de datos documentados, organizados y, aún así, capaces de implementarse eficazmente en un entorno de desarrollador único o desarrollador múltiple?".

Esto puede implicar procedimientos almacenados y otros scripts de objetos, pero especialmente esquemas, desde la documentación, hasta los nuevos scripts de actualización física, hasta el despliegue, y luego el círculo completo. Existen aplicaciones para que esto suceda, pero requieren enganches de esquema y sobrecarga. Me gustaría saber sobre las técnicas utilizadas sin una gran cantidad de terceros involucrados.

La manera más fácil que he visto esto sin la ayuda de una herramienta externa es crear un "parche de esquema" si se quiere. El parche de esquema es solo un simple script t-sql. El parche de esquema recibe un número de versión dentro del script y este número se almacena en una tabla en la base de datos para recibir los cambios.

Cualquier cambio nuevo en la base de datos implica la creación de un nuevo parche de esquema que luego se puede ejecutar en secuencia, que luego detectaría en qué versión está actualmente la base de datos y ejecutará todos los parches de esquema intermedios. Posteriormente, la tabla de versiones del esquema se actualiza con la fecha y la hora en que se ejecutó el parche para almacenarlo en la siguiente ejecución.

Un buen libro que entra en detalles como este se llama Refactoring Databases .

Si desea utilizar una herramienta externa, puede consultar el proyecto Ruby''s Migrations o una herramienta similar en C # llamada Migrator.NET . Estas herramientas funcionan creando clases c # / clases ruby ​​con una migración "Adelante" y "Atrás". Estas herramientas son más ricas en funciones porque saben cómo avanzar y retroceder en los parches de esquema. Sin embargo, como dijiste, no estás interesado en una herramienta externa, pero pensé que agregaría eso para otros lectores de todos modos.

siempre que agregue columnas / tablas a su base de datos, será una tarea fácil al programar estos cambios por adelantado en archivos sql. solo los ejecutas. tal vez tengas algún orden para ejecutarlos.

una buena solución sería crear un archivo por tabla, de modo que todos los cambios que pertenezcan a esta tabla sean visibles para quien esté trabajando en la mesa (es como trabajar en una clase). lo mismo es válido para procedimientos almacenados o vistas.

una tarea más difícil (y por lo tanto, quizás las herramientas serían buenas) es dar un paso atrás. siempre que solo agregue tablas / columnas, tal vez esto no sea un gran problema. pero si ha dejado caer columnas en una actualización y ahora tiene que deshacer su actualización, los datos ya no están allí. Deberá obtener estos datos de la copia de seguridad. pero tenga en cuenta que si tiene más de unas pocas tablas, esta podría ser una gran tarea, ¡y en el caso normal debería deshacer su actualización muy rápido!

si pudieras restaurar la copia de seguridad, está bien en este momento. pero, si actualiza el lunes, sus clientes trabajan hasta el miércoles y luego ven que faltan algunos datos (que acaba de abandonar de una tabla), entonces no podría simplemente restaurar la base de datos anterior.

Tengo un enfoque basado en modelos en mi mente (lo siento, no implementado en este momento) en el que los cambios de esquema son "modelados" (por ejemplo, por xml) y durante una actualización un procesador (por ejemplo, un programa #) crea todos los "sql" necesarios "y, por ejemplo, mueve los datos a una" dropDatabase ". los datos pueden residir allí, y si por alguna razón necesito restaurar algunos de los datos descartados, puedo simplemente hacerlo con el procesador. Creo que en algún momento (años) este enfoque no es tan malo porque, de lo contrario, los desarrolladores no tocan las tablas "antiguas" porque ya no saben si la tabla o columna es realmente necesaria. ¡Con este enfoque no arriesgas demasiado si dejas caer algo!

Lo que hago es:

  • Todos los comandos DDL necesarios para recrear el esquema (y los procedimientos almacenados y los índices, etc.) se encuentran en una secuencia de comandos.
  • Para asegurarse de que la secuencia de comandos está bien, se prueba de vez en cuando (crear una base de datos, ejecutar la secuencia de comandos y restaurar la copia de seguridad y comprobar que la base de datos funciona bien).
  • Para el control de cambios, la secuencia de comandos se mantiene en un Sistema de control de versiones (normalmente utilizo Subversion).

El truco es que, si no se puede bajar la base de datos para recrear con, digamos, una columna agregada, tengo que hacer dos cambios, un ALTER TABLE + una modificación en el script. Un poco más de trabajo pero, a largo plazo, gana.

En mi caso, tengo un script que se genera cada vez que cambio la base de datos, denominé el script como 00001.sql, n.sql y tengo una tabla con el número de último script que he ejecutado. También puede ver la documentación de la base de datos