Come manterrai i database sincronizzati e versionati in più ambienti?

Se si desidera ridurre al minimo la quantità di file necessari per eseguire le modifiche al database e preferire un singolo file di grandi dimensioni, è possibile utilizzare il seguente flusso di lavoro:

1. Scrivi un file 'di base' per creare le tue tabelle del database mentre sono in produzione
2. Sviluppa la prossima versione dell'applicazione, utilizzando uno o più file per le modifiche al database in quella versione
3. Distribuisci da zero allo sviluppo eseguendo il file di base, insieme ai file di modifica
4. Distribuire alla pre-produzione eseguendo i file contenenti le modifiche sul database di preproduzione, che è la stessa versione dello schema del file di base
5. Distribuisci alla produzione eseguendo i file contenenti le modifiche, che è la stessa versione dello schema del tuo file di base
6. Una volta che le modifiche arrivano alla produzione, crea un nuovo file 'di base' eseguendo la linea di base esistente, applicando le modifiche e creando una nuova linea di base da quel database.
7. Ripeti dal passaggio 2

Questo non è qualcosa che personalmente farei. Non c'è nulla di intrinsecamente sbagliato nell'avere un sacco di piccoli file per le modifiche al database perché:

• Controllo della versione può facilmente dirti perché si è verificata una modifica perché hai commesso lo script di modifica, che può essere molto utile
• La lettura di uno script di base per una grande applicazione è dolorosa, un buon strumento di visualizzazione del database lo rende molto più semplice
• L'impatto sull'esecuzione delle prestazioni nel piccolo script dovrebbe essere trascurabile
• Se hai mai una vecchia versione del database, l'aggiornamento alla versione più recente è facile perché hai ancora i singoli script di modifica
• Esistono strumenti per aiutarti a eseguire quei file e tenere traccia di quelli che devono ancora essere eseguiti come parte della distribuzione, il che aiuta se si urta un ambiente a una versione che ignora alcune versioni nell'intervallo

Per darti un'idea, una delle applicazioni su cui lavoro ha più di 14.000 linee di SQL su 34 file per creare un database di riferimento e utilizza oltre 1.000 script di modifica da quella base. Buona fortuna a leggere quello script di base.

Se puoi, chiedi a un gruppo o a una persona di gestire il modello o lo schema. Dal modello o dallo schema il DDL viene generato e applicato alle istanze del database. In questo modo non si mantengono gli script. Invece solo il modello del database e generare lo script (s) quando necessario. Questo dovrebbe includere tabelle, indici, trigger, ecc. Ci sono diversi strumenti sul mercato per renderlo gestibile.

I team applicativi dovranno mantenere le stored procedure o tutti i dati che devono essere inseriti / aggiornati per l'applicazione. Possono memorizzarli nel controllo del codice sorgente per archiviare gli ultimi e renderli riproducibili in modo che possano essere eseguiti più e più volte allo stesso effetto.

I carichi una tantum sono più difficili. Una strategia qui sarebbe quella di immagazzinare quelli sotto il controllo del codice sorgente. Si potrebbe avere una tabella nel database chiamata ONETIME o simile che memorizzerebbe tutti gli script di una volta che sono stati eseguiti in precedenza. Quando vengono eseguiti gli script, controlla semplicemente la tabella ONETIME per vedere se lo script è già stato eseguito contro l'istanza.

Questo dovrebbe rendere le cose più gestibili.