database - para - manual de programacion android pdf
en una aplicación web, ¿cómo se mantiene la estructura de la base de datos actualizada? (8)
Si sus datos cambian después de implementar la aplicación, ¿cómo mantiene la base de datos actualizada?
Quiero decir, puedes agregar o eliminar una tabla, es una tarea simple. 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 de la base de datos 10, 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 tales tareas?
Además, este sistema no parece perfecto si normalizo una tabla en un "parche" y después de eso me desnormalizo nuevamente por cualquier razón. Luego está hecho dos veces.
Pero escribir un guión 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 manera de ir desde cualquier punto.
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 ejecutan. Esto tiene una ventaja sobre una herramienta como SQL Compare (que me encanta) porque podemos modificar una vez los datos. 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 guión. 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, pero cuando actualizamos, 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 de un usuario ... debes escribir tus scripts para detectar que el estado original es el esperado y abortar si no es así.
Deberías buscar en 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ás pidiendo y mucho más.
En primer lugar, presentamos una tabla de versiones del esquema que rastrea el número de versión de la aplicación para la cual 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 desde 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.
Lo hago de la misma manera que tú. 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.
En paralelo, mantengo un modelo de base de datos (uso Azzurri Clay en Eclipse) para poder 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 bajo 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.
Muchos frameworks usan 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 del diseño de su aplicación. Una 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.
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.
Mantener los guiones de las versiones individuales, en mi humilde opinión, no solo son buenos para la implementación, sino que también son buenos para proporcionar elementos que pueden verificarse en el control de la fuente.
Probablemente deberías leer el artículo que Atwood escribió hace un tiempo sobre el control de la versión de DB sobre codificación de horror: ¿Está tu base de datos bajo control de versiones?
Utilice una herramienta como SQLCompare de RedGate u Objeto xSQL del software xSQL para generar sus secuencias de comandos T-SQL diff / delta 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.