Database Project in Visual Studio 2010

Visual Studio Database projects

Do your systems talk business? | 2

Autore

Ricci Gian Maria

E-mail: [email protected]

Blog: http://www.nablasoft.com/alkampfer

http://blogs.ugidotnet.org/rgm

mailto:[email protected]

http://www.nablasoft.com/alkampfer

http://www.nablasoft.com/alkampfer



ALM E DATABASE, LE PROBLEMATICHE ATTUALI

Parte prima


Database ed ALM - Problemi

• Difficoltà nel tracciare l’evoluzione degli oggetti• Difficoltà di effettuare una regressione ad una versione precedente

di un oggetto (In particolare tabelle)• Difficoltà di stabilire la paternità del codice delle stored procedure

Diffi coltà nel controllo di codice

• Effettuare il deploy del database in produzione• Aggiornare un database esistente in produzione• Gestire più installazioni con versioni di database differenti

Problemi di deploy

• Creare un database di test• Popolare il database di test con dati significativi

Diffi coltà di testing


Soluzioni tradizionali Database di sviluppo condiviso Aggiornamento tramite script sequenziali

Estrema difficoltà nel monitorare la vita degli oggetti

Assenza di script per il rollback delle modifiche

Difficoltà nell’individuare lo sviluppatore che ha scritto una specifica porzione di codice


Soluzioni tradizionali – Source Control

Il database è modellato da script sequenziali

ALTER TABLE CUSTOMER…ALTER VIEW ORDERBYCUST…

ALTER TABLE CUSTOMER…ALTER VIEW ORDERBYCUST…

CREATE TABLE SHIPPING…ALTER VIEW ORDERBYCUST…

CREATE TABLE SHIPPING…ALTER VIEW ORDERBYCUST…

ALTER TABLE CUSTOMER…ALTER TABLE SHIPPING…

ALTER TABLE CUSTOMER…ALTER TABLE SHIPPING…


Soluzioni tradizionali - Deploy Confronto con una struttura master per la generazione

di script di update

DEV Prod

Confronto con una struttura master per la generazione di script di update

Si deve generare uno script per ogni possibile versione che si ha in produzione

Problemi nel caso il database di produzione sia stato modificato


Soluzioni tradizionali - Testing Difficile gestire il database di test locale Generazione di script di creazione DB e procedure

manuali che ricreano il DB per i test Generazione di dati manuali.

DEV SCHEMASandbox

Test Data DB

Struttura

Dati

Test


Database Project Visual Studio Database Edition (Team System Developer o Team Suite)

introduce il concetto di Database Project

Un Database Project è un progetto dedicato per lo sviluppo di database

Lo scopo finale è garantire un’integrazione completa dello sviluppo DB nell’ALM

Get Latest

Modificare sorgente

Compilare

Eseguire testCheck In

Deploy Automatico

Test Centralizzati


Quando introdurre un Database Project nel ciclo produttivo Grazie all’importazione automatica è possibile introdurre un Database

Project anche in un progetto iniziato Le molte funzionalità fornite, tra cui il controllo sintattico e dei riferimenti

tra oggetti porta immediati vantaggi. E’ comunque necessario che gli sviluppatori abbiano una familiarità con lo

strumento, per cui è consigliabile un progetto pilota Operare immediatamente su un progetto relativo ad un database complesso

può essere dispersivo

DB Dev DB Project

Importazione

DEMO – FAMILIARIZZARE CON I DATABASE PROJECT


Ogni oggetto un file Il paradigma più importante è che ogni oggetto è identificato

da un file sorgente In questo modo è possibile confrontare le varie versioni e

monitorare l’evoluzione degli oggetti del database nel tempo Il database viene effettivamente “modellato” partendo da

dei file sorgente

CREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [Address] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…

CREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [Address] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…

CREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [MainAddress] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…

CREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [MainAddress] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…


Sviluppo dichiarativo Un database project contiene al suo interno tutte le dichiarazione di

creazione degli oggetti Si può passare dalla dichiarazione, alla generazione del database e di nuovo

al codice Nel database project sono contenute le definizioni di tutti gli oggetti che

compongono un database: tabelle, stored procedures, funzioni, utenti, assembly CLR, trigger, indici, etc.

Tutti questi file sorgente possono essere “compilati” per generare artefatti. Per contro gli sviluppatori necessitano della conoscenza della sintassi T-SQL

relativa alla creazione degli oggetti, ma si può sempre usare il Management Studio e poi portare il codice in Visual Studio

Ms Gui editing

Generate

Script

Upgrade DP


Database Logico Un Database Project definisce quindi un “database logico” che è

il risultato della compilazione di un database project

La compilazione individua eventuali errori di sintassi nelle definizioni degli oggetti

Vengono individuate anche anomalie, come riferimenti ad oggetti inesistenti


Compilazione

Progetto database

Schema Model

.dbschema

Analizzando i sorgenti viene creato lo schema model

Il modello viene Interpretato, analizzato e validato

Eventuali anomalie nel codice vengono comunicate con errori e warning, esattamente come avviene durante la compilazione di un normale progetto C# o VB


Compilazione

Validate

•La build valida gli oggetti del db

•Vengono validati anche i pre e post deployment script

Generazione

•Generazione dello Schema Model

•Generazione del file dbschema

•Generazione di tutti i file che costituiscono il database logico


Analisi di codice Procedura analoga a quella disponibile sui normali

progetti C# o VB Permette di analizzare il Database Project al fine di

evidenziare pattern di codice critici Suddivise in tre distinte categorie: Naming,

Performance e Design attivabili distintamente Possibilità di attivare/disattivare non solo le categorie

ma i singoli warning Mostra punti con possibili problemi nel codice.


Controllo di versione Visualizzando la storia di un file si ottiene la storia del

corrispondente oggetto del DB Si può effettuare un confronto tra le versioni per

vedere come un oggetto è cambiato nel tempo Si può capire chi e quando ha scritto una particolare

porzione di codice e perché Si può effettuare un rollback annullando le modifiche

DEMO – COMPILAZIONE E CONTROLLO DI CODICE SORGENTE


Deploy Il database logico può essere confrontato con un database

fisico per generare uno script di aggiornamento Il confronto non necessita di avere una istanza “viva” del

database di sviluppo

DB Logico DB Fisico

Confronto


Deploy in produzione Le modifiche possono anche essere applicate

immediatamente senza passare per uno script

DB Logico DB Fisico

Vengono generati alert in caso l’aggiornamento causasse una perdita di dati

Il confronto e l’aggiornamento vengono fatti tramite un tool ridistribuibile e gratuito, oppure direttamente da Visual Studio


Sincronia inversa Si può procedere anche in direzione inversa, ovvero

sincronizzare da un database fisico ad un database logico (solo da Visual Studio)

DB Logico DB Fisico

Questa procedura è utile, quando alcune persone non posseggono una versione che supporti i Database Project, ma debbono comunque poter modificare lo schema di database

Un’altra situazione è quella in cui un database di test viene ottimizzato da un DBA, che crea indici o modifica le viste direttamente in un’istanza di test.

In questo modo è sufficiente effettuare una sincronia al contrario per portare le modifiche, da un database reale, al Database Project


Gestire versioni multiple

Il database logico permette di sincronizzare versioni multiple

Non è necessario sapere a priori la versione per fare un aggiornamento

1.2

1.5

2.3


Come viene effettuato il deploy

Schema Model

Schema Model

Diff

Il confronto passa sempre per lo schema model

Le differenze vengono calcolate in base agli Schema Model

Sulla base delle differenze viene generato lo script di upgrade

Nella generazione si tiene conto delle caratteristiche delle varie versioni


Interfaccia per VsDbCmd.exe Il tool di deploy è un utility a riga di comando chiamato

VSDBCMD.exe Il formato “Riga di comando” è eccezionale per includerlo in

procedure automatiche di setup e di aggiornamento del db. L’essere ridistribuibile permette di includerlo in programmi di

aggiornamento senza spese di sorta Per semplificarne l’uso, un MVP Team System ha sviluppato una

interfaccia grafica che permette di specificare le opzioni tramite una GUI molto più user friendly rispetto alla modalità in riga di comando.

Ulteriori dettagli sul mio blog http://blogs.ugidotnet.org/rgm/archive/2009/10/14/una-mini-ui-per-vsdbcmd.exe.aspx

http://blogs.ugidotnet.org/rgm/archive/2009/10/14/una-mini-ui-per-vsdbcmd.exe.aspx

http://blogs.ugidotnet.org/rgm/archive/2009/10/14/una-mini-ui-per-vsdbcmd.exe.aspx

DEMO DEPLOY


Unit test del database Si possono creare con pochi click unit test di

stored procedure, trigger e funzioni

Aggiornamento struttura

Generazione Dati Esecuzione Verifica

risultati

Visual Studio si occupa di generare il database di test, allinearlo ed eseguire la generazione dati

Il test è scritto in T-SQL I test sono ripetibili e robusti.


Unit Test del database Sandbox: Ogni sviluppatore effettua i test nella sua macchina

locale I test non causano iterazione, ogni sviluppatore può testare in

completa autonomia La validità del Sandbox, sia come struttura e come dati viene

garantita dal Visual Studio Si evitano quindi i classici problemi legati al test del database

Database ProjectSandbox

Allineamento struttura

Generazione dati

Test

Data Generation Plan


Unit test del database Equiparazione tra database unit testing e code unit testing Strutturazione del test con il classico four phase test. Dietro le quinte è sempre presente un normale test C# o Visual Basic

generato dal designer, che costituisce il wrapper del database test. La classe wrapper può, se necessario, essere modificata per aggiungere

funzionalità

WrapperFixture Setup

Fixture Teardown

Test Setup

Test Cleanup

Test

T-Sql Code

T-Sql Code

T-Sql Code

T-Sql Code

T-Sql Code


Unit Test del database - Asserzioni

• RaiseError: per introdurre una asserzione tramite T-SQL è sufficiente lanciare una eccezione con RAISEERROR quando una condizione è violata

• In questo modo anche un DBA, o chi non conosce C# o VB può comunque interagire e scrivere test per il database

T-Sql

• Sono asserzioni effettuate da Visual Studio come: RowCount, ExecutionTime, EmptyResultset

• Possono essere espanse creando nuove regole.• Sono gestibili programmaticamente, come ad esempio in un

test DataDriven in cui i dati di test vengono presi da sorgenti esterne

Client Side


Data Generation Plan Motore di generazione di dati per test. Altamente configurabile Rispetta chiavi, relazioni e vincoli del database Genera dati in maniera ripetibile Può generare dati sulla base di dati preesistenti su un

database di test Espandibile con generatori custom per soddisfare

qualsiasi esigenza

DEMO UNIT TESTING


Refactoring Alcune operazioni su db sono molto invasive, come ad esempio

il rinominare una colonna di una tabella Grazie alla conoscenza della struttura, in un Database Project

questa operazione può essere automatizzata Il Visual Studio mostra tutte le modifiche che verranno

effettuate al progetto prima di aggiornare tutti gli oggetti che fanno riferimento all’oggetto modificato

È possibile avere una preview dettagliata per capire l’impatto che la modifica avrà nel database

I refactoring sono possibili sia per le tabelle, ma anche per altri oggetti, come trigger, stored procedures, funzioni


Refactoring - Dettagli Tabelle

Rename: Rinomina una tabella o colonna MoveToSchema: Sposta una tabella in uno schema differente FullyQualifyName: Qualifica in modo completo i nomi con il nome a tre

parti databasename.schema.name

View (tutte quelle delle tabelle più) ExpandWildcards: Analizza una stored ed ogni volta che viene trovato il

wildcard * in una selezione lo espande.

Stored e funzioni Rename: Rinomina una stored funzione o parametro MoveToSchema: Sposta una tabella in uno schema differente ExpandWildcards: Analizza una stored ed ogni volta che viene trovato il

wildcard * in una selezione lo espande. FullyQualifyName: Qualifica in modo completo i nomi con il nome a tre

parti databasename.schema.name


Altre caratteristiche Visualizzazione dipendenze

Permette di visualizzare, partendo da un oggetto radice, le dipendenze che esso ha nel database.

Vengono mostrati gli oggetti che dipendono dall’oggetto radice, ma anche gli oggetti da cui l’oggetto radice dipende

È possibile gestire le Extended Property dei vari oggetti Supporto dell’integrazione con CLR

Possibilità di aggiungere assembly al database project Gestione dei tipi nativi

Modella qualsiasi oggetto supportato dal motore di database Certificati Chiavi di sicurezza Utenti Code / Servizi Etc.

TIP AND TRICKS


Mantenere il numero di versione È sempre utile creare e mantenere una tabella con il numero di

versione nel database Nel post deploy script si aggiunge uno script per inserire il

numero di versione, solitamente si esegue un insert, in modo da conoscere tutte le versioni passate di un database

Fondamentale quando avvengono modifiche al db che non possono essere propagate automaticamente dal tool di aggiornamento struttura. In questo caso infatti un pre deployment script, può effettuare aggiornamenti specifici, conoscendo il numero attuale di versione.

Utile se da codice si vuole permettere di usare una versione vecchia del database senza forzare un aggiornamento.

Fondamentale per diagnostica, permette di capire la storia del database in caso di problemi


Ridurre le dimensioni degli script di reference

I file di riferimento delle strutture master sono molto grandi e rallentano molto il Visual Studio

Dato che sono file normali XML se ne può fare una copia e lasciare in essa solo le funzioni che si vogliono referenziare.

Questa operazione può cambiare drasticamente i tempi di apertura del progetto e di compilazione.

Necessario ogni qualvolta si faccia riferimento a funzioni base presenti nel database Master


Eseguire programmaticamente un data generation plan

Ai fini del testing può essere molto utile eseguire in maniera programmatica un Data Generation Plan

È possibile sfruttare msbuild da codice C# o VB per automatizzare l’operazione.

In questo modo si può decidere quando e quale piano di generazione eseguire prima di ogni test.

Test Data DBDatabase Project

Generation Plan


Integrazione con Team Build E’ possibile integrare il deploy del progetto DB in una

team build. Es, progetto web. In questo modo si automatizzano le procedure di deploy,

sia nell’ambiente di test che in produzione

DB Test

TFS

Check In

Build Server

Sincronizza DB

Aggiorna Web


Test In memoria Grazie al concetto di “variabili” è possibile parametrizzare i

sorgenti del progetto In particolare si può utilizzare un RAMDisk e far creare i file di

database in memoria Utilizzando questa tecnica per un deploy locale per gli unit

testing, si può velocizzare l’esecuzione.

Test in memoria


Test transazionali Un test transazionale è un test che non modifica il contenuto

del db È possibile rendere ogni test di database transazionale

semplicemente aggiungendo codice alla classe wrapper. In questo modo dopo ogni test il contenuto del database viene

riportato al contenuto iniziale, ed i test sono più ripetibili

WrapperFixture Setup

Fixture Teardown

Test Setup

Test Cleanup

Test

Begin Transaction

Execute test code

Rollback Transaction

DEMO UNIT TESTING


Estendibilità Il Visual Studio database edition può essere esteso in vari punti http://msdn.microsoft.com/en-us/library/aa833285(VS.100).aspx

Condizioni di test custom per gli unit test su oggetti di database Regole custom per l’analisi di codice Refactoring custom, sia definendo nuovi refactoring per tipi di oggetti

esistenti, sia definendo refactoring per tipi che di base non supportano refactoring.

Nuovi generatori dati.

http://msdn.microsoft.com/en-us/library/aa833285(VS.100).aspx


Database Supportati Visual Studio 2008 Database Edition GDR2

Sql Server 2000 Sql Server 2005 Sql Server 2008

Visual Studio 2010 Database Edition Aggiunto il supporto per Oracle tramite un plugin esterno chiamato

TeamFuze: http://www.teamfuze.net/index.jspa IBM ha annunciato il supporto a DB2, ma attualmente non c’è un link

pubblico per poterlo provare. L’intero modello della struttura di un database project è estendibile, è

quindi possibile virtualmente fornire supporto a qualsiasi tipologia di database relazionale.

http://www.teamfuze.net/index.jspa

http://www.teamfuze.net/index.jspa


Data Dude 2010 Alcune funzionalità sono presenti direttamente nella versione

Professional Per le team build non è più necessario installare la versione

completa DatabaseEdition per compilare progetti di database. Questo evita di usare una licenza per ogni macchina di build.

Maggiore estendibilità La nuova versione dei Database Project presenta alcune

migliorie ed innovazioni rispetto la versione attuale Intellisense: nell’editor del codice T-SQL è presente l’integrazione

dell’intellisense dell’editor di Sql Server 2008 R2 T-Sql debuger: integrazione del debugger di Sql Server 2008R2 all’interno

di Visual Studio 2010


Data Dude 2010 - Versioni

Visual Studio 2010 Premium/Ultimate

Visual Studio 2010 ProfessionalSchema Compare

Data Compare

Refactoring

Data Generation*

Database Unit Testing*

Static Code Analysis*

Project System IntelliSense

Build Deploy

Build Integration Command Line Deploy

Technology

Database Project in Visual Studio 2010