Controllo versione con SQL Server

Sto iniziando un nuovo progetto e utilizzo SVN (con Tortoise) come sistema di controllo della versione. Mi chiedevo se fosse possibile mantenere anche un database di SQL Server utilizzando lo stesso sistema.

Vorrei versioni delle mie tabelle / funzioni / viste / procs / trigger / ecc. ma non i miei dati in quanto saranno comunque tutti i dati di test. Non sono davvero sicuro di come configurarlo. Mi sono imbattuto in alcune opzioni, ma vorrei sapere se ce n'era qualcuno che mi mancava e se forse c'è una guida o qualcosa là fuori che mi aiuti a correre con esso.

Ho visto e sentito parlare di Red Gate, ma sto cercando qualcosa di gratuito (o almeno a costi molto bassi). So che potrei sempre scrivere qualcosa da solo, ma non sto davvero cercando di passare del tempo su questo.

Una cosa che ho scoperto è stato un pacchetto open source messo insieme chiamato ScriptDB4Svn . Qualcuno l'ha mai usato prima? È buono? Può fare le cose di cui ho bisogno ed è abbastanza semplice da configurare?

Tecnicamente non hai nemmeno bisogno di uno strumento, puoi scrivere direttamente gli oggetti e controllarli nel controllo del codice sorgente. È un po 'più di lavoro senza lo strumento, ma è sicuramente praticabile.

A proposito: ho usato lo strumento RedGate ed è piuttosto elegante e vale la pena.

Sembra che tu abbia una configurazione principalmente Microsoft. Puoi dare un'occhiata ai progetti di database (precedentemente noti come DataDude). Fondamentalmente trasformano T-SQL in un linguaggio di prima classe in Visual Studio; Puoi:

• Compila progetti: non si limita a creare uno script finale, ma assicura che esistano nomi di oggetti ecc.
• Esegui analisi di codice statico, ad esempio assicurandoti di fare sempre riferimento agli oggetti includendo il loro schema (ad esempio [dbo]nella maggior parte dei casi) per un buon aumento delle prestazioni del 30%.
• Crea script diff facendoli confrontare diverse versioni del progetto.
• Aggiorna il tuo progetto da un database o da uno script (reverse engineer).
• Intellisense.
• Non ci sono strumenti di diagrammi.

Unificano il codice e il codice del database anche sotto il controllo del codice sorgente. Se si elaborano e copiano gli oggetti del database (invece di utilizzare Davinci Tools in SSMS), si ottiene anche un IDE, il che è carino.

Puoi usare Rails. Rails ha un concetto di migrazioni di database che è possibile applicare o ripristinare. Nella mia esperienza, questo è il modo migliore per eseguire la versione di un database. Controlli questi file di migrazione in SVN.

Nel mio progetto attuale, non stiamo sviluppando l'applicazione in Ruby, ma stiamo ancora usando Rails per gestire il database. Non lo farei in nessun altro modo.

Questo è stato discusso in precedenza su StackOverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Inoltre, questo articolo esterno fornisce alcune informazioni aggiuntive http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated insieme al codice di esempio sotto forma di un'applicazione Windows.

Poiché quello che vuoi fare è qualcosa che ho fatto da solo per MS Access, ti dirò cosa ho fatto nel caso in cui ti dia alcune idee: ho scritto un modulo chiamato Ado2Xml che converte lo schema e i dati di qualsiasi ADO database accessibile a xml e viceversa. Conosce solo tabelle e viste; nessuna procedura memorizzata, nessun trigger, niente di niente. Ad ogni modo, nel tuo caso questo modulo viene sostituito dallo strumento che presumibilmente troverai che fa quello che vuoi con MS-SQL. Quindi, ogni volta che la mia applicazione viene avviata, confronta il timestamp del database con il timestamp del file xml salvato; se il file xml è più recente, distrugge il database e richiama Ado2Xml per ricrearlo dal file xml. Quando la mia applicazione termina, fa il contrario: invoca Ado2Xml per esportare il database nel file xml. In realtà, gli oggetti ADO che estraggono lo schema del database sono per qualche motivo terribilmente lenti, causando un certo tempo per il processo di esportazione. Quindi, per evitare di dover aspettare ogni volta che la mia applicazione venga chiusa e Visual Studio passi dal layout di debug al layout di modifica, proprio prima che termini la mia app avvia un'app esterna per eseguire l'esportazione, in modo che possa terminare subito.

Sì, ho usato uno strumento simile (sviluppato internamente) su un progetto precedente. Scriverebbe tutte le tabelle, le viste, gli sprocs, i trigger, ecc. In singoli file .sql. Quindi, abbiamo avuto uno script che veniva eseguito ogni notte per "convalidare" che tutto nel nostro database di "sviluppo" si riflettesse nel controllo del codice sorgente.

Quindi il normale flusso di lavoro è che cambieresti il ​​tuo codice, cambieresti le tabelle e gli sprocs corrispondenti nel database di sviluppo come richiesto, quindi avresti eseguito lo strumento che avevamo che avrebbe aggiornato tutti i file .sql con script. Quindi verifichi tutto in una volta.

Il problema era che se si fosse dimenticato di eseguire lo strumento, il codice avrebbe "funzionato" (e i test unitari sarebbero passati) perché il database era "corretto", ma i nuovi sprocs / table non sarebbero stati il ​​controllo del codice sorgente.

Quindi ogni sera abbiamo uno script che ha fatto un checkout del codice sorgente, quindi abbiamo creato lo strumento per aggiornare tutti gli script. Se c'è stata qualche differenza, significa che qualcuno ha dimenticato di controllare le proprie modifiche e che è stata generata una notifica via e-mail. Fondamentalmente era solo un modo per assicurarsi che non ci fossimo dimenticati di mantenere aggiornato il controllo del codice sorgente.

È stato un po 'fastidioso perché ha reso difficile lavorare su modifiche che si sono protratte per più giorni, ma era meglio che non avere nulla ...