MS SQL - Migrazione MySQL in una webapp legacy

Question

Desidero migrare il database di un'app Web legacy da SQL Server a MySQL. Quali sono i limiti di MySQL che devo cercare? E quali elementi farebbero parte di un elenco di controllo completo prima di passare alla modifica effettiva del codice?

Answer 1

La prima cosa che vorrei controllare sono i tipi di dati: l'esatta definizione dei tipi di dati varia da database a database. Vorrei creare un elenco di mappe che indichi a cosa mappare ciascuno dei tipi di dati. Ciò contribuirà a costruire i nuovi tavoli. Vorrei anche verificare la presenza di tabelle o colonne di dati che non vengono utilizzate ora. Inutile migrarli. Fai lo stesso con funzioni, lavoro, sps, ecc. Ora è il momento di ripulire la spazzatura.

Come si accede ai dati tramite sps o query dinamiche dal database? Controlla ogni query eseguendola contro un nuovo database di sviluppo e assicurati che funzionino ancora. Ancora una volta ci sono differenze tra il modo in cui funzionano i due sapori di SQl. Non ho usato il mio sql quindi non sono sicuro di quali siano alcuni dei punti di errore comuni. Mentre ci sei, potresti voler cronometrare nuove query e vedere se possono essere ottimizzate. L'ottimizzazione varia anche da database a database e mentre ci sei, probabilmente ci sono alcune query con prestazioni scarse in questo momento che puoi correggere come parte della migrazione.

Anche le funzioni definite dall'utente dovranno essere esaminate. Non dimenticarli se lo stai facendo.

Non dimenticare i lavori programmati, questi dovranno essere controllati e ricreati anche in myslq.

Stai importando dati su una pianificazione regolare? Tutte le importazioni dovranno essere riscritte.

La chiave di tutto è usare un database di test e testare, testare, testare. Metti alla prova tutto, in particolare i rapporti o i lavori trimestrali o annuali che potresti dimenticare.

Un'altra cosa che vuoi fare è fare tutto attraverso script che sono controllati dalla versione. Non passare alla produzione fino a quando non puoi eseguire tutti gli script in ordine sullo sviluppatore senza errori.

Answer 2

Una cosa che ho dimenticato, assicurati che il database di sviluppo da cui stai eseguendo la migrazione (il database del server sql) sia aggiornato dalla produzione immediatamente prima di ogni test. Odio avere qualcosa che non va in scena perché stavi testando record obsoleti.

Answer 3

Il codice client è quasi sicuramente la parte più complessa da modificare. A meno che l'applicazione non disponga di una suite di test di qualità molto elevata, alla fine dovrai eseguire molti test. Non puoi fare affidamento su qualcosa che funzioni allo stesso modo, anche su ciò che potresti aspettarti.

Sì, le cose nel database stesso dovranno cambiare, ma il codice client è dove si trova l'azione principale, avrà bisogno di un sacco di lavoro e test rigorosi.

Dimentica la migrazione dei dati, questa è l'ultima cosa che dovresti avere in mente; lo schema del database può probabilmente essere convertito senza troppe difficoltà; altri oggetti di database (SP, viste, ecc.) potrebbero causare problemi, ma il codice client è il punto focale dei problemi.

Quasi ogni routine che esegue una query del database dovrà essere modificata, ma assolutamente tutte dovranno essere testate. Questo non sarà banale.

Attualmente sto esaminando la migrazione del database principale della nostra applicazione da MySQL 4.1 a 5, che è una differenza molto minore, ma sarà comunque un compito molto, molto grande.