Migración gradual a un nuevo esquema de base de datos. ¿Sugerencias?

Question

(Esta pregunta es sobre la mejor manera de temporalmente y programáticamente mantener nuevos registros de dos bases de datos de sincronización, teniendo muy diferentes esquemas, e ignorando los viejos registros -outdated y ya no sea preciso:.)

Trabajo en una compañía que proporciona información de programación de TV para guías, periódicos y sitios web.

Tengo un sistema antiguo que tiene varias limitaciones y está siendo reemplazado por uno nuevo.

Diferentes clientes toman los datos en diferentes formatos (xml, sql, txt, incluso PDF listos para imprimir) y de diferentes maneras (push, pull, parcial dumps, simples exportaciones, exportaciones asistidas por el hombre -como la versión PDF-, etc.) Algunas exportaciones se generan una vez al mes, otras más de una vez al día.

El problema es que varios clientes tienen que confiar en los datos del sistema anterior hasta que el nuevo esté completamente desarrollado y cargado, y el personal que mantiene los datos no puede tener ambas bases de datos sincronizadas porque requeriría mucho de trabajo adicional, pero cambiar de sistema de la noche a la mañana parece imposible dado el tamaño del proyecto.

No queremos hacer un ingreso completo de los datos de la base de datos anterior a la nueva, porque la mayoría ya no es necesaria, y tienen mucha basura (es decir, registros duplicados con diferentes niveles de detalle) , información de aires antiguos que solo necesitamos como archivo).

Queremos que los nuevos registros se inserten en ambas bases de datos, y las antiguas se editen, se copien a la nueva base de datos también.

Estamos a punto de comenzar el desarrollo del nuevo sistema utilizando Symfony con Doctrine, y he decidido que podríamos diseñar un conjunto de clases de "proxy" ORM que deberían tener la misma interfaz que un simple conjunto de clases de Doctrine ORM , pero mantén la sincronización entre dos clases de clases (las que interactúan con el nuevo sistema y las que interactúan con la anterior). Eventualmente, el DB anterior debería descartarse junto con las clases de proxy, y las clases ORM de Doctrine que se conectan directamente al nuevo DB deberían tomar ese lugar, como si el sistema anterior nunca existiera.

Es una posibilidad remota, y no estoy completamente seguro con el enfoque.
¿Alguien tiene experiencia con este tipo de proyecto?
¿Conoce alguna falla común en este enfoque, o alguna otra solución que pueda adaptarse a esta situación?

Answer 1

No estoy seguro si hay un método para lograr esto, solo puedo recomendar que pruebe completamente el nuevo db antes de comenzar a migrar datos, una vez que esté seguro de que funciona como debería, le sugiero que escriba alguna aplicación de migración que consultaría los datos requeridos para ser exportados desde el antiguo db, no es necesario (pero debe) depurar los datos del antiguo db; si el nuevo db funciona, los datos duplicados deberían ignorarse por el restricciones

Solía ​​trabajar para una empresa a la que no le interesaban este tipo de problemas y al final era un completo desastre, parche tras parche, gritos y estrés insensible. Lo sé ... triste.