È il controllo del codice sorgente SQL RedGate per me?

Question

Ho appena ereditato un database SQL Server. Una delle cose che dovrò risolvere è la versione e le build automatizzate.

È stato suggerito che dovrei pensare seriamente a raccomandare RedGate SQL Compare, ma devo ammettere che sono un po 'a disagio a riguardo.

mie prenotazioni sono ...

• sembra per promuovere l'uso degli strumenti grafici per il lavoro db?
• per applicazioni live, preferisco lavorare con script di modifica, questo evita il panico dell'ultimo minuto per creare script di migrazione alla fine di ogni ciclo di Scrum e significa che gli script di aggiornamento possono essere testati dall'elemento della configurazione. Non riesco a vedere come lo strumento RedGate risolve questo problema.

Il mio istinto istintivo mi dice di seguire l'approccio collaudato di un file MSBuild e una pila di file .SQL.

Sarei interessato a sapere se qualcuno ha esperienza sull'utilizzo di questo strumento.

Answer 1

Preferirei anche degli script - facile da memorizzare nel controllo del codice sorgente (CVS, Git, ecc.) In modo da poter vedere se sono state apportate modifiche.

Answer 2

Non mi fido degli strumenti basati su diff per la distribuzione. E questo include i file .schema vsdbcmd, poiché anch'essi sono basati sulla diff. L'ultima volta che ho provato a utilizzare uno strumento diff è stato felice di modificare una tabella da 1,5 TB tramite copia/rilascio/rinomina ...

Il mio approccio è di utilizzare sempre upgrade scripts che sposta lo schema distribuito da v. N a v. N+1. In questo modo conosco esattamente come è fatto l'aggiornamento, e se un'operazione non è possibile (richiederebbe un'operazione di copia della dimensione dei dati della durata di 2 settimane ...) allora so che non posso farlo e pianifico il mio modifiche al codice per il rilascio di v. Quindi di conseguenza.

Answer 3

Utilizziamo Red Gate per generare script per la distribuzione e controllare il controllo delle versioni.

"Deployment" e "versioning" sono problemi separati per il codice SQL.

Importante da notare: il database di produzione è completo con tutti i suoi dati. Quindi organizzare copie regolari su un server di prova e utilizzarlo come riferimento. Un database generato da NUnit ogni notte con i dati di base (visto, riso) è generalmente inutile. Cosa succede se hai un miliardo di righe e devi testare una query contro di essa?

Versioning: è possibile utilizzare gli strumenti Red Gate per generare uno schema come base di riferimento e quindi confrontarlo con questa copia (o con il QA o qualsiasi altra cosa). Gli strumenti di Red Gate consentono il confronto con una cartella, che è sotto il controllo SVN nel nostro caso e viene aggiornata ogni versione. Così abbiamo la storia completa di ogni oggetto

Distribuzione: applichiamo i nostri script di sviluppo (anche in SVN) contro un ambiente pulito "costruire" DB e confrontare ad un altro DB pulito. Questo diventa il nostro script di implementazione.

Questo è abbastanza semplice, ovviamente.

La versione pro offre un'API per la sincronizzazione e il confronto in modo da poter essere integrata nella catena degli strumenti, se necessario. Nessuna GUI necessaria. Incidentalmente, lo usiamo per fornire una sincronizzazione in un clic di alcune sandbox utente speciali complete di codice client.

Come menzionato da Remus, non sono infallibili per alcune operazioni. Se stai cambiando materiale su tavoli da 1,5 TB, gestirò amorevolmente il mio script. Un'altra irritazione è che lo strumento di Red Gate ha l'abitudine di abbandonare SCHEMABINDING su una vista correlata o udf per un semplice controllo della modifica dei vincoli.

vi consiglio anche la lettura di Martin Fowler "Evolutionary Database Design" di qualche ispirazione

Answer 4

SQL Confronta può sia generare uno script di migrazione SQL che può essere rivisto in modo indipendente prima di applicarlo, ma dà anche la possibilità di eseguire lo script all'interno dello strumento. Red Gate consiglia di utilizzare il precedente metodo durante la distribuzione nei database di produzione.

Per il controllo delle versioni del database, SQL Source Control supporta la maggior parte dei sistemi di controllo del codice sorgente (ad esempio SVN, TFS, ecc., Sebbene il supporto VSS sia stato deprecato). C'è, in v3, un'opzione per il collegamento a una cartella di lavoro, che ti consente di utilizzare il tuo client di controllo della versione se lo desideri.

Answer 5

Possiedo un progetto di set di strumenti open-source (concesso in licenza con LGPL) che tenta di risolvere i problemi relativi al corretto controllo delle versioni dello schema DB per (e altro) SQL Server (2005/2008/Azure), bsn ModuleStore.

Fondamentalmente, la parte autonoma del set di strumenti esegue lo script degli oggetti DB di SQL Server di uno schema DB in file con una formattazione standard applicata, in modo che il contenuto del file cambi solo se l'oggetto ha realmente cambiato (molto in contrasto con scripting fatto da VS, che script anche alcune date di scripting ecc., contrassegnando tutti gli oggetti come modificati anche se sono in effetti identici).

Ma il set di strumenti va oltre se si utilizza .NET: consente di incorporare gli script SQL nella libreria o nell'applicazione (come risorse incorporate) e quindi di confrontare gli script incorporati con lo stato corrente nel database. Le modifiche non relative alla tabella (quelle che non sono "modifiche distruttive" come da Martin Fowler's definition) possono essere applicate automaticamente o su richiesta (ad esempio, creando e rimuovendo oggetti come viste, funzioni, stored procedure, tipi, indici) e cambiando script (che deve essere scritto manualmente però) può essere applicato nello stesso processo; vengono anche create nuove tabelle, opzionalmente insieme ai loro dati di configurazione. Dopo l'aggiornamento, lo schema del DB viene nuovamente confrontato con gli script per garantire un corretto aggiornamento del database prima di eseguire il commit delle modifiche.

Si noti che l'intero codice di script e confronto funziona senza SMO, in modo da non avere la dolorosa dipendenza SMO quando si utilizza il ModuleStore bsn nelle applicazioni.

A seconda di come si desidera accedere al database, il set di strumenti offre ancora di più - implementa alcune funzionalità ORM e offre un approccio molto interessante e basato sull'interfaccia per richiamare stored procedure, incluso il supporto trasparente per XML con nativo .NET. Classi XML e anche per TVP (parametri con valori di tabella) come IEnumerable<PocoClass>.

Answer 6

Usiamo uno strumento di confronto come parte del nostro processo di distribuzione per vedere se manca qualcosa che richiede uno script e poi andare a discuterlo con lo sviluppatore in caso affermativo (di solito è un differnce che non è controllato nel luogo di deplyment perché non dovrebbe essere spostato per andare a pungolo). Ma distribuiamo da script che si trovano sempre nel controllo del codice sorgente. Se ti affidi a SQL Compare o a qualsiasi altro strumento di confronto, potresti trovarti a spostare cose che non dovrebbero ancora essere spostate.