database - teoria - Migración utilizando el primer enfoque modelo en el marco de la entidad

teorias de la migracion pdf

Question

He configurado un sistema en el que tomé el primer enfoque del modelo, ya que tenía más sentido lógico para mí. Ahora, cuando tengo algunos cambios en el modelo, actualmente lo que hago es:

1. Use la función Generar base de datos desde el modelo del marco de la entidad. Creo una base de datos ficticia y aplico esos guiones. que elimina primero todos mis datos y tablas y luego actualiza la base de datos con el último archivo sql generado por entidad framework.
2. Ahora uso la función de comparación de esquema de Visual Studio y genero scripts de migración para mi base de datos local y también para la que está en producción.
3. Repaso las secuencias de comandos de forma manual y las verifico. Una vez hecho esto, ejecuto las secuencias de comandos de migración en las instancias de producción.

Pregunta : El principal problema es que es realmente tedioso y, como lo hago desde mi sistema local, conectarme a mis bases de datos prod es muy lento y, a veces, mi estudio visual también se cuelga. ¿Hay un enfoque más limpio para hacer esto? ¿Cuál es más automatizado de modo que mi computadora portátil no es realmente responsable de las migraciones de la base de datos en las instancias de producción?

Answer 1

Puede probar el paquete de energía de migración de base de datos : permite crear secuencias de comandos de cambio en lugar de secuencias de comandos de base de datos completas, pero detrás de ellas se realiza el mismo procedimiento que a mano. El problema es que la herramienta mencionada no funcionará con EF5 .

Lamentablemente, las migraciones de EF actualmente no son compatibles con los modelos creados a través de EDMX. Las migraciones solo admiten el primer enfoque de código en este momento.

Answer 2

En un diseño de Schema First, uso ApexSQL Diff (muy probablemente muy similar al producto de RedGate, quizás un poco más barato): una buena herramienta de terceros es mucho más fácil de usar que VS Database Project y es fácil de aplicar con una herramienta de aplicación de scripts como RoundHousE.

Utilizándolo en un enfoque Model First puede seguir el enfoque de Schema First utilizando un ciclo de Model-Schema-Diff-Schema-Model como se describe en la publicación; considere estas pautas / notas a continuación para un proceso simplificado. El enfoque schema-diff no necesita ser tedioso, lento o excesivamente manual.

1. La versión actual del esquema de base de datos se obtiene aplicando una secuencia de parches de base de datos (o scripts DDL / DML).

   Una herramienta (usamos RoundHousE) aplica automáticamente los scripts, según sea necesario. Registra información para saber qué scripts se han aplicado. Aplicar los mismos guiones es idempotente.

2. Diff hecho contra una base de datos local ; esta base de datos local se puede construir a partir de todos los scripts de cambios anteriores de manera automatizada. Este último local es siempre el objetivo diferencial para los últimos cambios de modelo.

   La base de datos remota / en vivo nunca se usa como un objetivo diff . Los mismos scripts se pueden aplicar más tarde a las bases de datos de prueba (y luego en vivo). Como todo se hace de la misma manera, el proceso es repetible en todas las bases de datos.

   El único "problema" es que una actualización que no está bien pensada puede dar lugar a datos que no son válidos bajo nuevas restricciones / restricciones. Por supuesto, esto fue fácil de identificar, corregir y volver a difintar antes de enviarlo a la base de datos en vivo.

3. Una vez que un diff se ha comprometido con el control de fuente, debe aplicarse en la rama. Para "deshacer" una secuencia de comandos de cambio previamente comprometida requiere crear una nueva diferencia aplicando una acción inversa. No hay una versión descendente implícita.

   Tenemos una rama de modelo [Hg] que actúa afectivamente como un bloqueo de esquema que debe ser unificado en contra; esto podría ser visto como un punto débil, pero ha funcionado bien con el desarrollo de equipos pequeños.

4. Una herramienta como Huagati DBML / EDMX se utiliza para sincronizar el Esquema de vuelta al Modelo, que es realmente útil cuando se desarrolla. Esta pequeña gema realmente se paga por sí misma y es parte del ciclo. Cuando se emplea esto, es fácil también "actualizar a un modelo" o hacer cambios en el esquema de SSMS (o lo que sea) y luego traerlos de vuelta.

Las migraciones de Code First son "OK" (¡y definitivamente mejor que nada!), Pero solo las estoy usando porque Azure SQL (también conocido como Base de datos SQL) no es compatible con herramientas diff avanzadas debido a que no se expone la información de varios sistemas. (Los diffs se pueden hacer localmente como de costumbre, pero ApexSQL Diff genera DDL / DML que no siempre es amigable con Azure SQL, además, es una oportunidad para mí de aprender un enfoque ligeramente diferente :-)

Algunas ventajas de las migraciones de Code First a través del Power Pack: pueden realizar tareas de actualización en C # en lugar de limitarse a DDL / DML (puede ser conveniente), degradaciones automáticas (aunque cuestiono su uso), no es necesario comprar un tercero herramienta (puede ser costosa), integración / implementación más sencilla para Azure SQL, menos vinculada a un proveedor de base de datos específico (en teoría), etc.

Si bien las migraciones de Code First (y la automatización de las mismas) son un buen paso adelante frente al enfoque absolutamente desagradable de Drop-and-Recreate, prefiero dedicar herramientas SQL al desarrollo.