en una aplicación web, ¿cómo se mantiene la estructura de la base de datos actualizada?

Question

Si sus datos cambian después de implementar la aplicación, ¿cómo mantiene la base de datos actualizada?

Quiero decir, puede agregar o quitar la tabla, es una tarea sencilla. Alterar una tabla existente también puede ser trivial. Pero si cambias la estructura a menudo, ¿cómo mantienes eso bajo control?

Solía ​​mantener una tabla con una versión actual de la base de datos en la base de datos. Luego, cada actualización fue un archivo SQL que hizo su trabajo: crear una nueva tabla, agregar una columna o mover los datos. Los archivos fueron nombrados después de esas versiones, así que si mi script de actualización obtuvo la versión 10 de la base de datos, simplemente tomó todos los archivos de 11.sql a N.sql y aplicó cada uno de ellos al incrementar el número de versión de la base de datos al mismo tiempo.

Esto parece estar funcionando bien, pero me pregunto: ¿cuál es su estrategia para esas tareas?
También este sistema no parece perfecto si normalizo una tabla en un "parche" y después de eso lo desnormalizo de nuevo por cualquier razón. Luego está hecho dos veces.

Pero escribir un script de actualización completo cada vez que cambio algo me parece doloroso y propenso a errores. Al menos más que tales cambios atómicos.

Además, puedo esperar que diferentes clientes tengan diferentes versiones de bases de datos ejecutándose en cualquier momento, así que realmente debería haber una forma de ir desde cualquier punto.

Answer 1

Personalmente utilizo un proceso muy similar al que ha enumerado, puedo ver su argumento sobre el cambio, pero MUY rara vez hago un cambio, luego lo cambio de nuevo al modo anterior en un sitio de producción. En las pruebas, sí, eso sucede, pero en términos de un sitio de producción real, no lo veo como un gran problema.

Manteniendo las secuencias de comandos de versión individual, en mi humilde opinión no solo son buenas para la implementación, sino que también son buenas para proporcionar elementos que se pueden controlar en el control de fuente.

Answer 2

Utilice una herramienta como RedQate SQLCompare u Objeto xSQL del software xSQL para generar sus scripts diff/delta T-SQL sobre la marcha.

Incluso puede integrarlo como parte de su proceso de compilación si lo desea.

Para diferentes clientes con diferentes bases de datos, simplemente tiene diferentes bases de datos de referencia con las que compara. Una vez que libera una actualización a un cliente, actualiza su propio sitio de referencia con el mismo script diff.

Eso es todo en pocas palabras.

Answer 3

Debería consultar una herramienta llamada Powerdesigner. Puede descargar una versión de prueba totalmente operativa de 15 días. Le ayudará a modelar, mantener los cambios actualizados, etc.

Es una gran herramienta para hacer lo que está pidiendo y mucho más.

Answer 4

Creamos un directorio para cada versión dentro de nuestro repositorio de control de versiones. Escribimos un script que lee los scripts en esa carpeta y los ejecuta en el orden de los archivos de los archivos (por lo que escribimos scripts con nombres como 32.0.0_AddColumnXxxxYyyy). Este formato punteado nos permite insertar scripts en la secuencia según sea necesario.

Cuando actualizamos un sitio, los nuevos scripts se detectan y se ejecutan. Esto tiene una ventaja sobre una herramienta como SQL Compare (que me encanta) porque podemos hacer modificaciones a los datos una sola vez.Sin embargo, ejecutamos SQL Compare y SQL Data Compare (en tablas seleccionadas) después de la actualización para garantizar que el procedimiento funcionó correctamente. Después de una ejecución exitosa, se compromete toda la operación y la base de datos actualiza la información de "ejecutar scripts" para que estos scripts no se vuelvan a ejecutar.

Lo bueno de hacerlo de esta manera es que no podemos "olvidar" un script. Además, cuando intentamos pasar a la base de datos de pruebas o etapas, a menudo encontramos suposiciones ocultas que los conjuntos de datos alternativos extraen antes de que llegue a la producción.

Otra ventaja de esto es que podemos mantener varias instalaciones en diferentes niveles de funcionalidad para diferentes clientes, sin embargo, cuando realizamos una actualización, todos los scripts están en su lugar y listos para ejecutarse. El único problema que he tenido con este esquema es un parche "fuera de servicio" que se aplica a la base de datos del usuario ... debe escribir sus scripts para detectar que el estado original es como se esperaba y cancelar si no.

Answer 5

Muchos marcos utilizan el concepto de "migraciones": scripts que actualizan su esquema de base de datos de una revisión a la siguiente revisión más alta. Del mismo modo, el script de degradación también es útil, en caso de que necesite desmantelar un cambio. A veces, estos scripts están en SQL, a veces se abstraen (por ejemplo, Ruby on Rails). Puede diseñar estos scripts a mano o utilizar una herramienta como SQL Compare que otros han mencionado.

También es útil crear una tabla en su base de datos con una columna, una fila, para indicar la revisión del esquema. Algunos marcos que admiten migraciones se basan en esto para saber qué scripts de migración aplicar para actualizar o degradar el esquema.

Su aplicación debe tener un conjunto de pruebas que pueda ejecutar para validar la funcionalidad de la aplicación. También podría agregar pruebas funcionales a este conjunto que inspeccione el esquema y confirme que existen las tablas, columnas, procedimientos, etc. esperados. Al revisar el proyecto, revise las pruebas. Del mismo modo que las pruebas de la funcionalidad de la aplicación deben seguirse en el control de origen junto con el código que prueban, también deben seguirse las pruebas de la estructura del esquema.

Finalmente, el diseño de la base de datos constituye la base de su diseño de aplicación. La ingeniería de software adecuada debería dar como resultado un esquema de base de datos relativamente estable antes de su implementación. Los cambios posteriores en el esquema de la base de datos deben ser pequeños e infrecuentes.

Answer 6

Lo hago de la misma manera que usted. Guardo un archivo de notas de la versión de la base de datos que tiene todos los cambios y el más reciente aparece en la parte superior con el número de revisión de subversión. También contiene el SQL que se ejecutó para aplicar este cambio.

Paralelamente, mantengo un modelo de base de datos (uso Azzurri Clay en Eclipse) para que pueda regenerar mi modelo en cualquier momento. Cualquier cambio que se requiera, primero lo hago en el modelo y luego actualizo mis Notas de la versión. Azzurri no puede generar ALTERACIONES solo a través de CREATE.

Todo esto se almacena en subversión para que pueda retroceder cuando sea necesario. Probablemente debería mantener algún tipo de vínculo entre la revisión svn de mi aplicación y la revisión de mi modelo.

Answer 7

En primer lugar, presentamos una tabla de versiones del esquema que rastrea el número de versión de la aplicación para la que se establece el esquema y rastreamos la versión de cada tabla invidual. tenemos una versión de esquema que codificamos duro en la aplicación para compararla con esta versión de la aplicación. No queremos que la aplicación acceda a la versión incorrecta de la base de datos. luego tenemos un conjunto de scripts para cada tabla que migra de la versión de la tabla anterior a la versión actual. luego tenemos una tabla de objetivos que incluimos en la aplicación para saber qué versión de cada tabla se espera en la nueva versión para ver si hacemos coincidir todo.si no, aplicamos los diversos scripts de migración al esquema para obtener el db hasta rapé.

complicado? algo. salvavidas. abosolutamente nada como perseguir errores en una aplicación porque el esquema es incorrecto.

Answer 8

Probablemente debería leer el aticle que Atwood escribió en el control de versiones de DB en la codificación de terror hace un tiempo: Is Your Database Under Version Control?