Come utilizzare il progetto del database SQL Server

Question

Sono in esecuzione SQL Server 2012 e VS 2010 con SSDT (SQL Server Data Tools) installato. Il mio DB di sviluppo utilizza stored proc, funzioni, oggetti CLR, ecc. Ha un'istantanea di dati di produzione di circa 500 GB.

Ho creato il progetto del database SQL Server e quindi ho importato il database. Questo ha creato tutti i file di tabelle, viste, proc e funzioni sotto nomi di schemi. Grandi cose - ora posso fare un controllo di versione proprio come in altri progetti VS, creare implementazioni, ecc. Fin qui, tutto bene.

Tuttavia, sono confuso su quale dovrebbe essere il mio processo di sviluppo per la modifica/aggiunta di proc/tabelle in Progetto database SQL Server. Sembra che tutte le modifiche apportate vengano applicate ad alcuni database LocalDb/Projects e NON al mio database di sviluppo.

Suppongo di voler creare tutti i miei oggetti in quel LocalDb, quindi creare e distribuire nel mio database di sviluppo tramite Pubblica? Sono preoccupato per le mie tabelle esistenti nel DB di sviluppo poiché se il processo di pubblicazione riduce e ricrea le tabelle, perderò lo snapshot dei miei dati di produzione.

Qual è il processo di sviluppo corretto da seguire nel progetto del database SQL Server?

Answer 1

1. Apportare modifiche all'interno del progetto VS DB.

2. distribuire le modifiche a LocalDB per testare

3. Pubblica il database al server di produzione. Preferisco usare Schema Compare per farlo manualmente, ma puoi anche pubblicare il progetto tramite il tasto destro del mouse -> menu di pubblicazione (che creerà anche un profilo di pubblicazione), o usando gli argomenti della riga di comando. Il processo di pubblicazione non verrà eliminato e non creerai tabelle (a meno che tu non dica di eliminare & per ricreare l'intero db).

In alternativa, nelle impostazioni del progetto è possibile modificare la stringa di connessione in modo che punti al server di produzione (come indicato nel commento). Tuttavia, vi consiglio di non farlo, poiché tenterà di pubblicare sul server di produzione ogni volta che eseguite una build locale (F5).

Answer 2

Pensare al database di origine (nel vostro caso, al progetto di database) come allo stato "da essere" dopo la distribuzione. Quando viene avviata una distribuzione, l'eseguibile (SqlPackage.exe) confronta la sorgente con la destinazione e genera uno script differenza/delta per rendere il target simile all'origine. Questo è il motivo per cui non è più necessario specificare CREATE o ALTER; lo strumento lo capisce. Per rispondere alla tua domanda sullo sviluppo continuo, puoi sviluppare in entrambi i modi. È possibile sviluppare nei file di progetto e pubblicarli su un database Dev comune (ad esempio, se si è membri di un team) oppure è possibile sviluppare nel database strumenti come SQL Server Management Studio (SSMS) e sincronizzarsi con i file di progetto con uno schema di confronto (io uso quest'ultima tecnica perché mi piace SSMS).

Per la distribuzione, è necessario che SSDT sia installato sulla macchina da cui si esegue la distribuzione (SSDT viene fornito con SQL Server 2012 e versioni successive; non si conosce SQL Server 2008). È possibile creare script per semplificare la distribuzione. In pratica chiamerai SqlPackage.exe (risiede in x: \ Programmi (x86) \ Microsoft SQL Server \ nnn \ DAC \ bin) con un'azione e una fonte. Uso anche Publish Profile per occuparmi della maggior parte delle proprietà del comando.Quindi, una distribuzione di esempio potrebbe assomigliare a questo:

SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml 

Per maggiori informazioni: Strumenti dati SQL Server Documentazione http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx

SqlPackage.exe Documentazione http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx