Gestire la migrazione delle modifiche del database non funzionanti a un database condiviso dalla vecchia versione della stessa applicazione

Question

Uno dei miei obiettivi è quello di essere in grado di distribuire una nuova versione di un'applicazione Web che esegue fianco a fianco la vecchia versione. Il problema è che tutto condivide un database. Un database che nella nuova versione tende a includere un significativo refactoring delle tabelle del database. Vorrei distribuire la nuova versione dell'applicazione agli utenti nel tempo e poterli riportare alla versione precedente, se necessario.

Oren ha avuto un buon post che risolve il problema, ma si è concluso con:

" Siamo ancora in acque un po 'confuse per quanto riguarda la distribuzione alla produzione per quanto riguarda le modifiche che interessano l'intero sistema, vale a dire, rompendo le modifiche al database. Discuterò che nella prossima puntata, questa è stata un po 'fuori controllo, temo. & Quot;

Il post successivo non è mai arrivato ;-). Come gestiresti la migrazione delle modifiche del database non funzionanti a un database condiviso dalla vecchia versione della stessa applicazione. Come mantenere sincronizzati i dati?

Answer 1

Se la vecchia versione deve essere mantenuta, le modifiche semplicemente non possono essere interrotte. Questo aiuta anche quando si distribuisce una nuova versione di un'app Web: se è necessario eseguire il rollback, davvero aiuta se è possibile lasciare il database così com'è.

Ovviamente questo comporta notevoli svantaggi architettonici e quasi sicuramente finirai con un database che mostra la sua discendenza, per così dire - ma i vantaggi della distribuzione di solito valgono il mal di testa, nella mia esperienza.

Aiuta se hai una solida collezione di test di integrazione per ogni vecchia versione coinvolta. Dovresti essere in grado di eseguirli sul tuo database di test migrato per ogni versione che è ancora considerata "possibilmente attiva". - che potrebbe benissimo essere " ogni versione mai " in alcuni casi. Se sei in grado di controllare la distribuzione in modo ragionevolmente rigoroso, potresti cavartela solo con la compatibilità per tre o quattro versioni, nel qual caso puoi pianificare l'eliminazione graduale di tabelle / colonne obsolete, ecc. Se ce n'è davvero bisogno. Basta ricordare la complessità di tale pianificazione rispetto ai benefici maturati.

Answer 2

Leggi il libro di Scott Ambler " Database di refactoring " ;; prendere con un pizzico di sale, ma ci sono un sacco di buone idee lì dentro.

I dettagli delle soluzioni disponibili dipendono dal DBMS in uso. Tuttavia, puoi fare cose come:

• crea una nuova tabella (o diverse nuove tabelle) per il nuovo design
• crea una vista con il vecchio nome della tabella che raccoglie i dati dalle nuove tabelle
• crea i trigger "anziché" sulla vista per aggiornare le nuove tabelle anziché la vista

In alcune circostanze, non hai bisogno di una nuova tabella, potresti semplicemente aver bisogno di trigger.

Answer 3

Supponendo solo 2 versioni del tuo client, terrei una sola copia dei dati nelle nuove tabelle.

Puoi mantenere il contratto tra la vecchia e la nuova app dietro le viste in cima alle nuove tabelle. Usa prima / invece dei trigger per gestire le scritture nel "vecchio" visualizzazioni che effettivamente scrivono nelle nuove tabelle.

Stai mantenendo 2 versioni di codice e devi comunque sviluppare la tua vecchia app ma è inevitabile.

In questo modo, non ci sono problemi di sincronizzazione, in effetti dovresti affrontare i conflitti di replica tra "vecchio". e "nuovo" schemi.

Più di 2 versioni diventano complicate come menzionato ...

Answer 4

In primo luogo, vorrei dire che questo problema è molto difficile e potresti non trovare una risposta completa.

Ultimamente sono stato coinvolto nel mantenimento di una linea di applicazioni aziendali legacy, che potrebbe presto evolversi in una nuova versione. La manutenzione include la risoluzione di bug, l'ottimizzazione del vecchio codice e nuove funzionalità, che a volte non si adattano facilmente all'attuale architettura dell'applicazione. Il problema principale con la nostra applicazione è che è stato scarsamente documentato, non ci sono tracce di modifiche e siamo sostanzialmente il 5 ° team di rotazione che lavora a questo progetto (ne siamo abbastanza nuovi).

Lasciando da parte i dettagli esterni (codice, livelli, ecc.), proverò a spiegare un po 'come stiamo attualmente gestendo le modifiche al database.

Al momento abbiamo due regole che stiamo cercando di seguire:

1. In primo luogo, è che il vecchio codice (sql, stored procedure, funzioni, ecc.) funziona così com'è e deve essere mantenuto così com'è, senza modificare troppo a meno che non ci sia il caso (modifica di bug o funzionalità), e di ovviamente, prova a documentarlo il più possibile (specialmente i problemi come: " WTF !, perché lo ha fatto invece di quello? ").

2. Il secondo è che ogni nuova funzionalità che arriva dovrebbe usare le migliori pratiche conosciute in questo momento e modificare la vecchia struttura del database il meno possibile. Ciò introdurrebbe alcune opzioni di refactoring del database come l'uso di viste modificabili in cima alla vecchia struttura, l'introduzione di nuove tabelle di estensione per quelle già esistenti, la normalizzazione della struttura e la fornitura della struttura precedente tramite viste, ecc.

Inoltre, stiamo provando a scrivere quanti unit test possiamo fornire agli analisti aziendali che lavorano fianco a fianco e documentano le regole aziendali.

Il refactoring del database è un campo molto complesso a cui rispondere in una risposta breve. Ci sono molti libri che rispondono a tutti i tuoi problemi, uno http://databaserefactoring.com/ indicato in uno delle risposte .

Modifica successiva: si spera che la seconda regola risponda anche alla gestione delle modifiche non consentite.