Versioning SQL Server DDL code

Question

Mi piacerebbe avere tutto il codice DDL DB in CVS.

Stiamo usando Subversion per il nostro codice .NET ma tutto il codice del database rimane ancora non verificato.

Tutto ciò che sappiamo è quanto può essere importante la logica DB. Ho cercato su Google, ma ho trovato solo pochi (strumenti costosi). Credo che esistano altre (più economiche) soluzioni.

Quale approccio consiglia di seguire? Quali strumenti sono più appropriati?

SQL Server 2005, VS 2008 TS, TSVN

UPDATE Il nostro scenario di codifica è che gli sviluppatori non possono accedere al CODICE DB direttamente. È cambiato solo da script (quindi questo non è un problema)

Sono principalmente interessato all'ambiente DEV in cui tutti gli sviluppatori hanno pieno accesso.
Quindi accade che uno sviluppatore sovrascriva USP precedentemente modificato da un altro.
Mi piacerebbe avere la possibilità di ripristinare la versione perso/confrontare USPs revisioni ecc

UPDATE 2-
Per creare script di distribuzione che stiamo usando Red-Gate SQL Confronta.
Funziona perfettamente, quindi gli script di distribuzione non sono un caso.

Answer 1

finalmente ho trovato questo strumento e approccio estremamente utile e molto facile introdurre
(almeno all'inizio - in cui nessuna soluzione delle versioni sul posto):

http://www.codeproject.com/KB/database/SQLScripter.aspx

È possibile eseguire fuori della scatola.
Per la soluzione finale preferirei la GDR.

Answer 2

Se non l'hai già letto, l'articolo di Martin Fowler Evolutionary Database Design è un ottimo punto di partenza.

L'articolo è difficile da riassumere, ma descrive come il suo team ha affrontato il controllo delle versioni del database in un processo di sviluppo in rapida evoluzione. Hanno creato i propri strumenti per facilitare le cose: script per portare gli utenti al master attuale, per copiare qualsiasi versione dello schema in modo che gli utenti possano eseguire il debug delle copie di lavoro degli altri, ecc.

Per una solida soluzione a bassa tecnologia, Ho trovato utile mantenere due tipi di script DDL nel controllo del codice sorgente:

• Una versione master che può creare gli oggetti del database da zero.
• Script 'aggiornamento versione' per ogni iterazione di sviluppo.

Sono ridondanti in una certa misura, ma estremamente utili (in particolare quando si tratta di distribuzione).

Answer 3

Se si utilizza Visual Studio Team Suite o Visual Studio Developer Edition, si ha diritto a una copia di Visual Studio Database Professional. Questo è progettato per fare esattamente quello che descrivi e molto altro. Lo usiamo per gestire il nostro schema di database (codice).

Randy

Answer 4

Se non l'hai già guardato il Visual Studio Database Edition GDR (anche noto come"Dati Dude"), si dovrebbe assolutamente scaricarlo e provarlo:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

Tra le altre cose, la DDR faciliterà team di sviluppo, rendendo più facile per ogni sviluppatore di mantenere la propria copia locale di un database, script di versione, creare script di distribuzione per spostare uno schema di database in una nuova versione e persino supportare il rollback del database.

È gratuito se si utilizza la versione per sviluppatori di team system. Controlla.

Answer 5

Utilizziamo anche Subversion per tutti i nostri codici di database. Dal momento che nulla è permesso di andare a Prod a meno che non sia in una sceneggiatura, sembra che non ci sia alcun problema nel portare le persone a mettere tutti gli script in sovversione. Tendiamo a scrivere script di tabelle di alterazione per modificare tabelle con dati esistenti e quindi ricreare l'intera struttura di tabella nel caso in cui sia necessario creare un nuovo database da zero (spesso abbiamo la stessa struttura di database su più server poiché alcuni dei nostri client sono molto grandi e non vogliono che i loro dati siano accidentalmente disponibili alla concorrenza e quindi pagano server separati e quindi potrebbe dover creare nuovamente l'intero database senza dati.) Per gli oggetti che non memorizzano direttamente i dati, rilasciamo l'oggetto originale e lo ricreamo con una dichiarazione di creazione. Ogni progetto ha la propria casa nel repository e ogni database lo fa, quindi lo script potrebbe trovarsi in più di un posto per facilitare la distribuzione.

Ma la vera chiave è che nessuno può caricare su Prod senza uno script. Non concediamo ai nostri sviluppatori diritti diretti sui pungoli, quindi non hanno problemi a fare cose negli script piuttosto che usare SSMS.

Answer 6

Questo sembra anche interessante:

Gratuito:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133

commerciale:
http://www.nobhillsoft.com/Randolph.aspx

Answer 7

Vedere se Wizardby si adatta alle vostre esigenze.

Answer 8

Ho scritto SMOscript che genera uno script CREATE per ogni oggetto in un database.

Utilizzare questo strumento per generare in una directory coperta da CVS e aggiornare il repository.

Answer 9

È necessario utilizzare Management Studio (SSMS) e inserire il .sql nel controllo del codice sorgente, possibilmente separare gli oggetti dello schema nelle cartelle. Spero che questo aiuti