Visual Studio Team Edition for Database Professionals (VSDBPro)

Visual Studio Team Edition for Database Professionals (VSDBPro) consente di gestire la definizione del vostro schema di database di SQL Server allo stesso modo di come gestite i vostri progetti per applicazioni.
Si parte dal rappresentare lo schema del database all’interno del progetto di database .dbproj (Figura 1), dopodichè viene creata automaticamente una collezione di frammenti T-SQL DDL (Data Definition Language). Ogni frammento è memorizzato in un singolo file .sql e rappresenta un unico oggetto dello schema, ad esempio una tabella, una constraint, una Stored Procedure, ecc. Poiché i file sql rappresentano un singolo oggetto dello schema, il rilevamento delle modifiche e delle versioni di questi oggetti dello schema è molto più semplice e preciso.

Dopo aver definito il progetto di database sono disponibili due viste:

– la vista Solution Explorer presenta la struttura fisica di tutte le directory ed i file utilizzati per archiviare gli oggetti all’interno del progetto (Figura 2);
– la vista Schema che fornisce una rappresentazione logica dello schema completo organizzato da schema e / o tipo di oggetto (Figura 3).

Ora che abbiamo una collezione di frammenti di SQL, come facciamo a distribuire lo schema con le modifiche incrementali?

A questo punto entra in gioco il processo di Build di un progetto database, che prende tutti i frammenti SQL all’interno del progetto e li confronta con lo schema all’interno del database di destinazione (Target Database) e ne valuta le differenze secondo la logica rappresentata in Figura 4.

La Build richiede due ingressi: lo stato del progetto; che è “ciò che si vuole” (poichè tutte le modifiche si apportano al progetto e non al database) e il database di destinazione, che è “quello che si ha”. Il risultato del confronto è un insieme di oggetti dello schema che sono differenti, e sono ordinati in modo da rispettare le dipendenze nell’ordine corretto.
Il motore di Build determina questa informazione sulle dipendenze durante il caricamento del progetto mediante analisi ed interpretazione di tutti i frammenti DDL per tutta la durata del progetto.
Alla fine, genera uno script di distribuzione (deploy) sotto forma di un script .SQL, che contiene una serie di statement T-SQL DDL per aggiornare in modo incrementale lo schema sul server database di destinazione.
Questo riduce drasticamente la necessità di creare e gestire manualmente la cronologia degli script di aggiornamento incrementale per mantenere il vostro schema del database aggiornato (up-to-date). Io, ad esempio, ero abituato al classico versionamento 001_script1.sql, 002_script2.sql, ecc.

Il grande cambiamento è che ora il progetto di database è la sorgente della definizione dello schema, e non viene distribuito sull’istanza del database target fino a che non si effettua il deploy.
Dal momento che il progetto di database è il “centro della verità” per il nostro schema del database, si ha che mettendo il progetto sotto Source Control (ClearCase, SourceSafe, TFS, ecc..) si ha la possibilità di integrare il Data Layer sul ciclo di vita dello sviluppo: ossia si ha il controllo delle versioni degli oggetti dello schema (Figura 5).

Tutto ciò consente l’immissione del progetto sotto il controllo del codice sorgente (SCC), il versioning degli oggetti dello schema individuale, e il tracking dei cambiamenti di questi oggetti. Consente inoltre l’allineamento nel versioning tra l’applicazione (business logic, presentation, ecc..) ed il livello dati (data layer). Entrambi i layer possono utilizzare le stesse etichette (label di versioning) per indicare le versioni nel tempo, possono essere effettuati i branch e tutto quanto concerne il source controlling.