Controllo versione con SQL Server


14

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?


1
Has anyone used this before? Is it good? Can it do the things I need it to do and is it pretty simple to get setup?Perché hai paura di provarlo tu stesso? Basta prenderlo e giocare.
yannis,

@YannisRizos - Sicuramente lo farò se non ottengo troppa risposta da questo, in pratica volevo solo provare a risparmiare un po 'di tempo e vedere se qualcuno ci aveva lavorato prima o se qualcuno aveva provato e testato subito adatto alle mie esigenze in modo da poter risparmiare un po 'di tempo di sperimentazione.

Ho appena notato quanto sei nuovo qui. I programmatori SE non sono un buon posto per porre domande solo per risparmiare un po 'di tempo, ci aspettiamo davvero che tu faccia cose del genere per te, cioè fai le tue ricerche prima di fare . Oppure, in alternativa, chiedi in chat (ma non aspettarti risposte solide). Detto questo, non importa davvero perché quest'ultima frase non è la tua domanda principale, che in realtà è un'ottima domanda (e correttamente taggata, cosa rara per i nuovi utenti, complimenti!).
yannis,

@YannisRizos - grazie. Salterò nella chat per vedere se riesco a ottenere un feedback per ScriptDB4Svn e ricontrollerò qui per eventuali aggiornamenti alla domanda principale. Modifica: sembra che non possa chattare fino a quando non ho 20 rep. Oh bene, la pazienza immagino.

Risposte:


2

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.


Quindi, fondamentalmente, farei il mio lavoro in Management Studio, e quindi esporterei gli script nella directory SVN, e fondamentalmente lo farei ogni volta che ci lavoro (sostituendo quelli vecchi ogni esportazione)? Immagino che funzionerebbe. Manterrebbe la funzionalità SVN di essere in grado di ripristinare e roba, ma sì, sarebbe una seccatura. Forse darò un'occhiata ai prezzi di RedGate e vedrò se ne vale la pena.

@Scott - Il modo manuale può funzionare, devi solo pensare allo sviluppo di SQL in modo diverso. Le versioni con script degli oggetti sono quelle "ufficiali" e quella in SQL è solo una versione compilata di esso. Proprio come il tuo codice sorgente.
JohnFx,

Ho deciso di fare le cose manualmente e possibilmente implementare uno script usando l'aiuto nei collegamenti forniti da Mike Nakis, ma per ora userò la GUI integrata in Management Studio per esportare gli script di creazione del DB quando avrò finito funzionante, controlla quelli e lascia che SVN li mantenga aggiornati. Da quando ho deciso di fare le cose manualmente, ottieni la risposta per sottolineare che non ho davvero bisogno di uno strumento per fare queste cose :)

1

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.


0

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.


Qualche guida per spiegarlo un po 'di più e iniziare a creare qualcosa del genere?

In realtà, non è una buona idea usare Rails insieme alle tecnologie .NET.
altern

Capitolo sulle migrazioni di Rails ( guide.rubyonrails.org/migrations.html ). Questo dovrebbe essere sufficiente per iniziare e darti tutto lo sfondo necessario sul perché questa è una buona idea. @altern: poiché stai solo utilizzando Rails per manipolare e versioni del database, ciò dovrebbe avere un impatto sulle tecnologie .NET. Puoi accedere al DB e utilizzarlo come se non avessi utilizzato i binari. Non mi dispiacerebbe vedere alcuni riferimenti alle tue preoccupazioni. IronRuby non è un'implementazione .Net di Ruby and Rails?
Vinnie,

> IronRuby non è un'implementazione .Net di Ruby and Rails? IronRuby è un'implementazione .NET di Ruby . Non sono sicuro che Rails funzioni correttamente su IronRuby. La mia argomentazione generale contro l'utilizzo di Rails ai fini del versioning di db è che Ruby e le relative tecnologie (RoR, migratinos) hanno una curva di apprendimento piuttosto ripida, specialmente per compiti così semplici come il versioning di db. Va bene usarlo per altri scopi, non solo per le migrazioni. Altrimenti, aumenterà la complessità del progetto senza molti effetti positivi.
altern

0

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.


I due link che hai fornito sono qualcosa che probabilmente mi interessa ottenere da solo, quindi posso sostanzialmente automatizzare i passaggi manuali che sto facendo in questo momento. Grazie per quelli!

0

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


Puoi approfondire Then, we had a script that ran every night to "validate" that everything in our "development" database was reflected in source control.? Grazie per la risposta.

@Scott: ho modificato la risposta per includere un po 'più di dettaglio.
Dean Harding,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.