SQL Source Control si inserisce in SSMS e collega i tuoi database al tuo sistema di controllo della versione, permettendoti di controllare la versione dei tuoi schemi di database, e poi distribuirli usando il fidato motore di confronto di Redgate SQL Compare.
L’ultima versione (spedita questa settimana!) presenta una versione migliorata degli script di migrazione, che ti permettono di scrivere il tuo SQL per sovrascrivere lo script di distribuzione generato da SQL Compare, rendendo possibile per i tuoi compagni di squadra ottenere le ultime modifiche dal controllo di versione senza il rischio di perdere dati. Potete saperne di più su quello che abbiamo fatto, e perché, in un altro mio recente blogpost.
Ma qui, volevo parlarvi di come funziona usando uno scenario comune.
Come evitare la perdita di dati quando si rinomina una tabella
I compiti comuni che potrebbero essere interessati includono la divisione o la fusione di colonne e tabelle, l’aggiunta di un vincolo NOT NULL a una colonna, la modifica del tipo di dati o della dimensione di una colonna e la rinomina di una tabella.
Nel caso di rinomina di una tabella sul vostro database di sviluppo, SQL Source Control interpreterebbe questo cambiamento come un DROP e CREATE. Se un altro membro del tuo team usa la scheda Get latest per ottenere queste modifiche, i dati nella tabella di destinazione vengono persi.
Per evitare questa perdita di dati, puoi scrivere uno script di migrazione per rinominare la tabella usando la stored procedure sp_rename. Questo script sostituisce le istruzioni DROP e CREATE che il motore SQL Compare genererebbe altrimenti per questo cambiamento.
Una volta che avete rinominato la vostra tabella (in questo caso da utenti a clienti) il passo successivo sarebbe quello di impegnare le modifiche al vostro sistema di controllo delle fonti utilizzando la scheda Commit changes in SQL Source Control. SQL Source Control vi avvertirà che potrebbe verificarsi una perdita di dati commettendo la modifica e vi suggerirà di scrivere uno script di migrazione.
Nella scheda Migrazioni e sotto Sostituisci le modifiche allo schema non commesse, dovrete usare le caselle di controllo per selezionare le modifiche allo schema pertinenti.
In questo esempio state sostituendo i cambiamenti di schema non impegnati perché avete già rinominato la tabella, ma non l’avete ancora impegnata. La rinomina viene interpretata da SQL Compare come un DROP e un CREATE e lo script di migrazione sostituirà queste modifiche nello script di distribuzione (l’altra opzione sarebbe quella di iniziare con uno script vuoto, cosa che faresti se avessi già preparato il tuo schema per la migrazione e impegnato queste modifiche).
Facendo clic su Generate script SQL Source Control genera uno script di migrazione basato sulle modifiche non impegnate e tu puoi quindi sostituire le istruzioni DROP e CREATE generate automaticamente.
in questo caso useremo il seguente SQL:
EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO
Il sinonimo per la tabella clienti qui eviterà problemi quando la tabella è referenziata con il vecchio nome.
Poi potete salvare e chiudere e questo script di migrazione ora sostituisce le modifiche fatte.
Nella scheda Commit vedrete lo script di migrazione con le modifiche allo schema associate annidate sotto. Quindi tutto quello che devi fare è selezionare il nuovo script di migrazione, inserire un commento e impegnare le modifiche.
Sei ora pronto per distribuire le modifiche. Se stai usando SQL Compare allora lo script di migrazione viene eseguito automaticamente durante il deployment, usando la stored procedure sp_rename al posto delle dichiarazioni DROP e CREATE originariamente generate dal motore SQL Compare.