Sembra che tu abbia un problema di stabilità nella progettazione del tuo database. Lavora per stabilizzare il design. I dati tendono a rimanere fermi per anni. Il tuo controllo della versione del database sembra funzionare, ma sembra avere a che fare con un design di database troppo volatile.
Il database è il tuo livello di persistenza. Se si eliminano frequentemente tabelle e colonne, non sembra che si abbia una buona padronanza su ciò che è necessario mantenere. In anni di pratica, non ricordo di aver bisogno di rinominare una colonna che era stata prodotta. Anche l'aggiunta di tabelle e colonne è relativamente infrequente.
Considera l'applicazione del principio Aperto / Chiuso alla progettazione del tuo database. Ciò potrebbe richiedere di dedicare un po 'più di tempo a chiarire le tue esigenze.
Per la maggior parte dei sistemi che ho lavorato con una nuova versione di codice, viene fornito con uno script di aggiornamento che apporta le modifiche necessarie per tale versione. Ciò potrebbe includere l'aggiunta di tabelle, colonne e dati, modificare colonne e dati esistenti e tabelle o colonne cancellate raramente.
Esistono metodi che consentono di progettare le modifiche in modo che siano compatibili con la versione esistente. Molti di questi sono ben coperti dal principio Open / Closed. (Non modificare le colonne in modo da interrompere il codice esistente. Fornisci un meccanismo predefinito per le nuove colonne che devono essere popolate.)
Non hai fornito dettagli sufficienti per fornire una soluzione per la tua applicazione. Ho costruito sistemi con revisioni al database di produzione ogni mese. È necessario analizzare come le modifiche funzioneranno con la versione esistente e nuova del codice. Raramente puoi inserire un nuovo database come un nuovo set di codice.
Ci sono molti progetti open source da database che trattano gli stessi problemi. Quelli che ho usato hanno sempre script di aggiornamento e spesso hanno script di downgrade. Lo script di solito copre solo una versione. Il codice che esegue l'aggiornamento applicherà tutti gli script di upgrade o downgrade richiesti per passare da una versione alla successiva. Avere downgrade degli script è fantastico quando è necessario eseguire il debug di un problema che potrebbe essere stato introdotto in una versione precedente.
Sebbene sia possibile avere script di upgrade / downgrade che coprono più release, è probabile che lo sforzo di testing superi il vantaggio. Se hai seguito il principio Apri / Chiuso, dovrebbe essere raro che tu stia applicando e annullando le modifiche durante l'aggiornamento o il downgrade di più versioni.
Esistono strumenti che generano le modifiche dello schema tra lo schema corrente e lo schema desiderato. Ti lasciano ancora il problema e gli aggiornamenti dei dati che sono necessari. Assicurarti di aver capito bene quando colonne e tabelle potrebbero essere state aggiornate, rinominate e aggiornate di nuovo sarà molto difficile.