Controllo versione con SQL Server

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 lavorabile.

BTW: Ho usato lo strumento RedGate ed è piuttosto lucido e vale i soldi.

Sembra che tu abbia una configurazione per lo più di Microsoft. Puoi dare un'occhiata a Progetti di database (precedentemente noti come DataDude). Fondamentalmente trasformano T-SQL in un linguaggio di prima classe in Visual Studio; puoi:

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

Unificano anche il tuo codice e il tuo codice di database sotto il controllo del codice sorgente. Se man-up e script i tuoi oggetti di database (invece di usare Davinci Tools in SSMS), finisci anche tu usando un IDE - che è bello.

Puoi usare Rails. Rails ha un concetto di migrazione dei database che è possibile applicare o eseguire il rollback. Nella mia esperienza questo è il modo migliore per fare la versione di un database. Controlla questi file di migrazione in SVN.

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

Questo è stato discusso prima su stackoverflow: link

Inoltre, questo articolo esterno fornisce alcune informazioni aggiuntive link insieme al campione codice sotto forma di applicazione Windows.

Dato che quello che vuoi fare è qualcosa che ho fatto da solo per MS Access, ti dirò cosa ho fatto nel caso ti desse qualche idea: ho scritto un modulo chiamato Ado2Xml che converte lo schema e i dati di qualsiasi database accessibile da ADO 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 rimpiazzato dallo strumento che presumibilmente troverai che fa ciò che vuoi con MS-SQL. Pertanto, ogni volta che viene avviata l'applicazione, 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 termina la mia applicazione, 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 po 'di tempo per il processo di esportazione. Quindi, per evitare di dover attendere ogni volta che la mia applicazione termina e lo studio visivo per passare dal layout di debug al layout di modifica, appena prima che termini la mia app avvia un'app esterna per eseguire l'esportazione, in modo che possa terminare immediatamente.

Sì, ho usato uno strumento simile (sviluppato in-house) su un progetto precedente. Scriverà tutte le tabelle, le viste, le estensioni, i trigger, ecc. In singoli file .sql. Quindi, avevamo uno script che veniva eseguito ogni notte per "validare" che tutto nel nostro database "di sviluppo" si rifletteva nel controllo del codice sorgente.

Quindi il normale flusso di lavoro è che cambieresti il codice, modificheresti le tabelle e gli sprocs corrispondenti nel database di sviluppo come richiesto, quindi eseguiresti lo strumento che avremmo dovuto aggiornare tutti i file .sql con script. Dovresti quindi controllare tutto in una volta.

Il problema era che se avessi dimenticato di eseguire lo strumento, il codice sarebbe "funzionante" (e i test unitari sarebbero passati) perché il database era "corretto", ma i nuovi sproc / tavoli non sarebbero il controllo del codice sorgente.

Quindi ogni notte, abbiamo uno script che ha fatto un checkout del codice sorgente, quindi rand lo strumento per aggiornare tutti gli script. Se c'era qualche differenza, significa che qualcuno ha dimenticato di controllare le modifiche e che è stata generata una notifica via email. Fondamentalmente era solo un modo per assicurarci di non dimenticare di mantenere aggiornato il controllo del codice sorgente.

Era un po 'fastidioso perché rendeva difficile lavorare a modifiche che si estendevano per più giorni, ma era meglio che non avere nulla ...