Introduzione ai Database Project con Visual Studio
Scritto da
Antonio Pierascenzi
il
mercoledì 8 febbraio 2012
Linguaggio:
•
Framework:
•
Livello: 100
Download pdf
Questo articolo rappresenta un vademecum per la creazione di una
soluzione necessaria per modificare un database
esistente. Dopo aver creato un progetto di tipo
database project, disponibile anche
sottoforma di un comodo wizard ma facendo attenzione a non
scegliere un database server project (che crea un progetto con
preimpostato lo scheletro di un applicazione con CLR abilitato su
Sql Server), ci viene chiesto da quale database sorgente dobbiamo
importare schema o tabelle. Fatto questo e scelto fra le varie
opzioni disponibili in riferimento ai parametri di impostazione del
database su cui stiamo lavorando, possiamo procedere nelle
modifiche eventuali ai database. Dobbiamo prestare attenzione
nel fatto di apportare le modifiche solo ed esclusivamente
nel progetto creato d'ora in poi (nel caso in cui dovessimo
modificare il database dobbiamo fare uno Schema
Compare, tra la sorgente scelta inizialmente e lo
schema del progetto, disponibile dal menu
Data e lanciare gli update del
caso).
Per il nostro scopo abbiamo scelto un database identico sia in
fase di import che come target del progetto, questa attività
rappresenta anche uno dei punti successivi da testare.
Il punto dove vorremmo soffermarci in questo articolo è il deploy
che, dopo aver buildato la soluzione per verificare la coerenza e
la consistenza delle modifiche apportate, provvede ad aggiornare le
stesse sul database target.
Le impostazioni di deploy richieste in fase di creazione del
progetto, sono disponibili nelle proprietà del progetto nel tab
Deploy.
Fig.1
Nell'opzione Deploy Action decidiamo
eventualmente di effettuare direttamente le modifiche in fase di
deploy o di farci creare esclusivamente lo script da lanciare
manualmente (anche da VS2010 come ben sapete), così come possiamo
decidere un target db diverso nel caso dovessimo deployare le
modifiche ad es. su db di produzione.
Ci sono altre impostazioni che andrebbero approfondite e che sono
raggiungibili anche dal ramo delle
Properties, che ci permettono di avere un
controllo più capillare del progetto.
Fig.2
In particolare per la proprietà
Database.sqldeployment esistono diverse
opzioni di "peso" :
Fig.3
Accessibile attraverso la scelta del pulsante
Edit.. nella
sezioneDeployment configuration file
Fig.4
Di rilevanza per la maggior parte dei casi sono in particolare
due, di cui una impostata a True:
- Block incremental deployment…..
che blocca il deploy nel caso in cui sono presenti delle possibili
perdite di dati a causa di modifiche del tipo su una colonna di una
tabella (es. da char(100) a char(50)
- Generate drop statements for objects
… che genera nello script di deploy uno statement DROP per
quegli oggetti presenti nel target db ma non nel database project,
questa impostazione è false di default.
Per il test sul deploy su altri istanze di server e db c'è da
annotare un aspetto fondamentale: dobbiamo ricordarci che il
database project in fase di impostazione iniziale del progetto in
relazione al database target, crea un percorso fisico in locale per
il database e per il file di log. Questo può andar bene quando il
deploy viene fatto sullo stesso db target (ossia coincidono le due
istanze) mentre ovviamente non può esserlo nel nostro test. Per
ovviare a questo inconveniente dobbiamo semplicemente eliminare i
relativi file dalla solution e fare tranquillamente il deploy della
solution che ricreerà i percorsi corretti, dopo aver ovviamente
modificato nelle impostazioni di deploy il nuovo db di
destinazione.
Il percorso dove si trovano i file è:
Fig.5
Nell'immagine sono stati già eliminati.
Per evitare, nelle fasi di test, di fare direttamente dei deploy
sui database, reimpostiamo nelle property del progetto, la
deploy action su : Create a deployment
script(.sql)
Fatto questo si può procedere al deploy che evidenzierà il
funzionamento degli obiettivi previsti e la creazione del fle
<nome_progetto>.sql nella directory
debug o release del progetto e, contemporaneamente, della
<nome_progetto>.dll nella directory
debug\release del progetto web.
Data generation
Normalmente la generazione di dati di test per un database di
sviluppo avviene o attingendo da un backup di un database in
produzione o scrivendo i record a mano.
Ovviamente Visual Studio 2010 ci offre uno strumento potente e
flessibile per l'obiettivo prefissato, che necessita
dell'aggiunta di un nuovo file di tipo
.dgen contenente la definizione
dello schema del database su cui stiamo lavorando ivi comprese le
impostazioni della collation.
Il design che ci viene fornito ci permette di modificare le
proprietà di ogni singola colonna del database a livello di tipo di
generatore di dati, che in generale sono standard ma è possibile
crearne altri personalizzati.
Fig.6
Come si può vedere, avendo impostato sul nostro database un
check-constraints nella colonna Phone che controlla l'inserimento
di valori superiori a 9 caratteri, abbiamo utilizzato una
banalissima Regular Expression : [0,9]{10,}. E limitato la
lunghezza massima a 30 (Maximum Length).
Fatto questo possiamo procedere a vedere un anteprima dei dati che
verranno inseriti attraverso il menu Data ->Data
generator -> Preview Data generation e, se tutto è
come volevamo, possiamo procedere alla generazione vera e propria
sempre dallo stesso menu voce Generate
Data.
Ci comparirà una dialog box di scelta del database di destinazione
e un successivo messaggio in cui ci viene chiesto se vogliamo
eliminare o meno i dati presenti nel database prima di
continuare.
Ovviamente questo articolo è lontano dall'essere esaustivo ma
rappresenta un primo semplice passo verso l'integrazione del
"codice" sql verso il controllo del versioning con Team Foundation
Server.
Riferimenti :
Overview Database
Project
Tags: