database - exportar - migrar base de datos sql server 2008 a 2014

Migración de datos desde la estructura de datos heredada a la nueva estructura de datos (3)

En primer lugar, parece una situación muy complicada, y no creo que haya una solución "limpia". He pasado por situaciones similares un par de veces, no fueron muy divertidas.

En primer lugar, el esfuerzo de cambiar las aplicaciones de los clientes va a ser importante: si el dominio subyacente cambia (al introducir el concepto de una dirección separada de una persona, por ejemplo), las aplicaciones del cliente también cambian; no es solo un cambio. en la forma de acceder a los datos. La mejor manera de evitar este dolor es escribir su capa de API para reflejar el modelo de dominio de negocio del futuro y pegar el esquema de su base de datos anterior en eso; si hay nuevos conceptos que no puede reflejar utilizando los datos anteriores (por ejemplo, "get / app / addresses / addressID"), ejecute un error NotImplemented. Donde pueda reflejar el nuevo modelo con los datos antiguos, conéctelo lo mejor que pueda y vuelva a factorizarlo bajo las sábanas.

En segundo lugar, eso significa que necesita crear versiones en su API como una preocupación de primera clase, por lo que puede decirle a los clientes que en la versión 1, las características x, y y z arrojan excepciones "NotImplemented". Cada versión debe ser compatible con versiones anteriores, pero agrega nuevas características. De esta forma, puede refactorizar las características en la versión 1 siempre que no rompa el servicio e implemente la característica x en la versión 1.1, la función y en la versión 1.2, etc. Idealmente, tenga una hoja de ruta para sus versiones y notifique a la aplicación del cliente propietarios si vas a dejar de apoyar una versión, o lanzar un cambio radical.

En tercer lugar, un conjunto de pruebas de integración automatizadas para su API es la mejor inversión que puede hacer: confirman que no ha roto las funciones a medida que se refactoriza.

Espero que esto sea de alguna utilidad. No creo que haya una sola respuesta directa a su pregunta.

Ok, aquí está el problema al que nos enfrentamos.

Actualmente:

Tenemos un montón de aplicaciones heredadas que tienen acceso directo a la base de datos
La estructura de datos en la base de datos no está normalizada
El proceso / estructura actual es utilizado por casi todas las aplicaciones

Lo que estamos tratando de implementar:

Mueva toda la funcionalidad a un servicio RESTful para que ninguna aplicación tenga acceso directo a la base de datos
Implementar una estructura de datos normalizada

El problema que tenemos es cómo implementar esta migración no solo con las aplicaciones, sino también con la base de datos.

Nuestra solución actual es:

Identificar toda la funcionalidad de CRUD e implementar esto en el nuevo servicio web
Crea las nuevas aplicaciones para reemplazar las aplicaciones heredadas
Señale las nuevas aplicaciones al nuevo servicio web (sigue apuntando a la estructura de datos anterior)
Migre los datos en las bases de datos a la nueva Estructura
Apunte las nuevas aplicaciones al nuevo servicio web (señale la nueva estructura de datos)

Pero a medida que discutimos este proceso, buscamos reescribir el Nuevo Servicio Web dos veces. Una vez para la estructura de datos anterior y una vez para la estructura de datos nueva, ya que actualmente no podríamos representar la estructura de datos anterior para que se ajuste a la nueva estructura de datos para el nuevo servicio web.

Quería saber si alguien ha enfrentado desafíos como este y cómo superó estos tipos de problemas / implementación y demás.

Lo que parece que debe hacer es definir un nuevo modelo de datos ("normalizado") y crear una asignación del modelo normalizado de nuevo al modelo heredado. A continuación, puede reemplazar las llamadas directas heredadas con llamadas en el normalizado en su tiempo libre. Esto no rompe el código.

Paralelamente, debe definir lo que equivale a una API heredada (cerntralizada) y asignarla a su modelo normalizado. Ahora, en su tiempo libre, reemplace las llamadas de base de datos heredadas originales con llamadas en la API de db heredada. Esto no rompe el código.

Una vez que las llamadas originales se reemplazan por completo, puede cambiar el modelo de datos al real normalizado. Esto no debería romper ningún código, ya que ahora todo va en contra de la API db heredada o la API db normalizada.

Finalmente, puede reemplazar las llamadas de API db heredadas y el código relacionado, con un código revisado que utiliza la API de datos normalizada. Esto requiere una cuidadosa recodificación.

Para acelerar todo esto, desea una herramienta de transformación de código automatizada para implementar los reemplazos de código.

Este documento parece tener una buena visión general: http://se-pubs.dbs.uni-leipzig.de/files/Cleve2006CotransformationsinDatabaseApplicationsEvolution.pdf

EDITAR : Más explicaciones de la sincronización usando disparadores bidireccionales; actualizaciones de sintaxis, lenguaje y claridad.

Preámbulo

He enfrentado problemas similares en una actualización del modelo de datos en una aplicación web grande en la que trabajé durante 7 años, por lo que siento tu dolor. A partir de esta experiencia, propondría algo un poco diferente, pero espero que sea mucho más fácil de implementar. Pero primero, una observación:

El valor para la organización son los datos: los datos sobrevivirán por mucho tiempo a todas sus aplicaciones actuales. La empresa constantemente inventará nuevas formas de obtener valor de los datos que ha capturado, lo que engendrará nuevos informes, aplicaciones y formas de hacer negocios.

Así que obtener la nueva estructura de datos correcta debería ser su objetivo más importante. No intercambie la estructura correcta contra otras metas de desarrollo a corto plazo, especialmente:

Objetivos operacionales como el despliegue de un nuevo servicio
Informe el rendimiento (utilice vistas materializadas, activadores o trabajos por lotes en su lugar)

Esta estructura cambiará con el tiempo, por lo que su arquitectura debe permitir adiciones frecuentes y normalizaciones infrecuentes. Esto significa que la estructura de datos y las API compartidas (incluidos los servicios RESTful) deben tener la versión adecuada.

¿Por qué los servicios web RESTful?

Menciona que su voluntad "Mover toda la funcionalidad a un servicio RESTful para que ninguna aplicación tenga acceso directo a la base de datos". Necesito hacer una pregunta muy importante con respecto a las aplicaciones heredadas: ¿Por qué es esto importante y qué valor ha traído?

Pregunto porque:

Pierdes transacciones ACID (cada llamada es una transacción única a menos que implementes unas horriblemente complicadas normas WS- *)
El rendimiento se degrada: las conexiones directas a la base de datos serán más rápidas (no habrá trabajo del servidor web y las traducciones) y tendrán menos latencia (típicamente 1ms en lugar de 50-100ms) lo que reducirá visiblemente la capacidad de respuesta en aplicaciones escritas para conexiones DB directas
La estructura de la base de datos no se abstrae del servicio RESTful, porque usted reconoce que con la normalización de la base de datos debe reescribir los servicios web y volver a escribir las aplicaciones que los llaman.

Y las otras preocupaciones transversales no han cambiado:

Capacidad de administración: las conexiones de bases de datos directas se pueden monitorear y administrar con muchas herramientas genéricas aquí
Seguridad: las conexiones directas son más seguras que los servicios web que sus desarrolladores escribirán
Autorización: el modelo de permiso de la base de datos es muy avanzado y tan preciso como podría desear
Escalabilidad: el servicio web es una (¿única?) Aplicación de base de datos conectada directamente y, por lo tanto, se escala solo en la misma medida que la base de datos.

Puede migrar la base de datos y mantener las aplicaciones heredadas en funcionamiento manteniendo una API RESTful heredada. Pero, ¿y si podemos mantener las aplicaciones heredadas sin introducir un servicio RESTful "heredado"?

Control de versiones

Presumiblemente, la mayoría de las aplicaciones ''heredadas'' usan SQL para acceder directamente a las tablas de datos; es posible que tenga varias vistas de la base de datos también.

Un enfoque para la migración de datos es que la nueva base de datos (con la nueva estructura normalizada en un nuevo esquema) presenta la estructura anterior como vistas a las aplicaciones heredadas, generalmente desde un esquema diferente.

En realidad, es bastante fácil de implementar, pero solo resuelve los informes y la funcionalidad de solo lectura. ¿Qué pasa con la aplicación heredada DML? DML se puede resolver usando

Vistas actualizables para transformaciones simples
Introducción de procedimientos almacenados donde las vistas actualizables no son posibles (por ejemplo, "CALL insert_emp (?,?,?)" En lugar de "INSERT INTO EMP (col1, col2, col3) VALUES (?,??)".
Tener una tabla ''heredada'' que se sincronice con la nueva base de datos con activadores y enlaces de base de datos.

Tener una tabla de formato heredado con sincronización bidireccional a la (s) nueva (s) tabla (s) de formato que usa desencadenadores es una solución de fuerza bruta y relativamente fea.

Usted termina con datos idénticos en dos esquemas diferentes (o bases de datos) y la posibilidad de que los datos se salgan de sincronización si el código de sincronización tiene errores, y luego tiene los problemas clásicos del problema de los "dos maestros". Como tal, trátelo como último recurso, por ejemplo, cuando:

La estructura fundamental ha cambiado (por ejemplo, el cambio de la cardinalidad de una relación), o
La traducción al formato heredado es una función compleja (por ejemplo, si la columna heredada es el cuadrado del valor de la columna de formato nuevo y se establece en "4", una vista actualizable no puede determinar si el valor correcto es +2 o -2) .

Cuando se requieren tales cambios en sus datos, habrá algún cambio significativo en el código y la lógica en alguna parte . Podría implementar en una capa de compatibilidad (ventaja: no cambiar el código heredado) o cambiar la aplicación heredada (ventaja: la capa de datos está limpia). Esta es una decisión técnica del equipo de ingeniería.

La creación de una base de datos de compatibilidad de la estructura heredada utilizando los enfoques descritos anteriormente minimiza los cambios en las aplicaciones heredadas (en algunos casos, la aplicación heredada continúa sin ningún cambio de código). Esto reduce en gran medida los costos de desarrollo y prueba (para los cuales no hay ganancia funcional neta para el negocio), y reduce en gran medida el riesgo de despliegue.

También le permite concentrarse en el valor real de la organización:

La nueva estructura de la base de datos
Nuevos servicios web RESTful
Nuevas aplicaciones (potencialmente compiladas usando los servicios web RESTful)

Aspecto positivo de los servicios web

No lea lo anterior como una diatriba contra los servicios web, especialmente los servicios web RESTful. Cuando se usa por la razón correcta, como para habilitar aplicaciones web o la integración entre sistemas dispares, esta es una buena solución arquitectónica. Sin embargo, puede que no sea la mejor solución para administrar sus aplicaciones heredadas durante la migración de datos.