Migrazione graduale a un nuovo schema di database. ¿Suggerimenti?

Question

(Questa domanda è circa il modo migliore per temporaneamente e programatically tenere nuovi record di due database in sincronia, avendo molto diversi schemi, e ignorando i vecchi dischi -outdated e non più necessario-.)

Lavoro su un'azienda che fornisce informazioni sulla programmazione TV per guide, giornali e siti Web.

Ho un vecchio sistema che ha diverse limitazioni e viene sostituito da uno nuovo.

Diversi client acquisiscono i dati in diversi formati (xml, sql, txt, anche PDF pronti per la stampa) e in diversi modi (push, pull, dump parziali, esportazioni semplici, esportazioni assistite dall'uomo, come la versione PDF, eccetera). Alcune esportazioni vengono generate una volta al mese, altre più di una volta al giorno.

Il problema è che diversi client devono fare affidamento sui dati dal vecchio sistema fino a quando il nuovo è completamente sviluppato e caricato e lo staff che gestisce i dati non può avere entrambi i database sincronizzati perché richiederebbe molto di lavoro aggiuntivo, ma i sistemi di commutazione durante la notte sembrano impossibili data la dimensione del progetto.

Non vogliamo creare un intero completo dei dati dal vecchio database a quello nuovo, perché la maggior parte di essi non è già necessaria e ha un sacco di spazzatura (cioè, record duplicati con diversi livelli di dettaglio , vecchie informazioni di spedizione che abbiamo bisogno solo di un archivio).

Vogliamo i nuovi record inseriti in entrambi i database e quelli vecchi in fase di modifica, copiati anche nel nuovo database.

Stiamo per avviare lo sviluppo del nuovo sistema utilizzando Symfony con Doctrine e ho deciso di progettare un set di classi "proxy" ORM che dovrebbero avere la stessa interfaccia di un semplice set di classi Doctrine ORM , ma mantieni la sincronizzazione tra due altri gruppi di classi (quelle che si interfacciano con il nuovo sistema e quelle che si interfacciano con quella precedente). Alla fine il vecchio DB dovrebbe essere scartato insieme alle classi proxy e le classi di ORM Doctrine che si connettono direttamente al nuovo DB dovrebbero prendere quel posto, come se il vecchio sistema non sarebbe mai esistito.

È un tentativo lungo, e non sono completamente sicuro dell'approccio.
Qualcuno ha esperienza con questo tipo di progetto?
Sai qualche errore comune in questo approccio o qualche altra soluzione che potrebbe adattarsi a questa situazione?

Answer 1

Non sono sicuro che ci sia un metodo per farlo, posso solo raccomandare di testare completamente il nuovo db prima di iniziare la migrazione dei dati, una volta che sei sicuro che funzioni come dovrebbe, ti consiglio di scrivere alcune applicazioni di migrazione che interrogano i dati richiesti per essere esportati dal vecchio db, non è necessario (ma si dovrebbe) eseguire il debug dei dati dal vecchio db, se il nuovo db funziona, i dati duplicati dovrebbero essere ignorati dal restrizioni.

Ero abituato a lavorare per un'azienda che non si prendeva cura di questo tipo di problemi e alla fine era un disastro completo, patch dopo patch, urla e stress non necessario. Lo so ... triste.