16. class AuctionApplication
class AuctionApplication
class AuctionApplication
( ( ( App
int id;
int id; int id;
void MethodA();
void MethodA();
string cacheTitle;
) void MethodB();
void MethodA();
) void MethodB();
)
V1 V2 V3 Revision History
CREATE ALTER TABLE dbo.Auction
TABLE ALTER TABLE dbo.Auction
dbo.Auction Database
( WITH CHECK ADD CONSTRAINT
WITH CHECK ADD CONSTRAINT
id INT NOT PRIMARY KEY (id)
Au_PK Au_SK UNIQUE (name)
NULL,
name VARCHAR(25) NOT NULL,
start DATETIME NULL,
len INT NULL
)
17. -- version 1 Add table dbo.Auction
IF OBJECT_ID (N'dbo.Auction', N'U') IS NULL
BEGIN
CREATE TABLE dbo.Auction
(
id INT NOT NULL,
name VARCHAR(25) NOT NULL,
start DATETIME NULL,
len INT NULL
)
END
-- version 2 Add PK Au_PK
IF NOT EXISTS (SELECT * FROM sys.key_constraints WHERE name = 'Au_PK' AND type = 'PK')
BEGIN
ALTER TABLE Auction
WITH CHECK ADD CONSTRAINT Au_PK PRIMARY KEY (id)
END
-- version 3 Add UC Au_SK
IF NOT EXISTS (SELECT * FROM sys.key_constraints WHERE name = 'Au_SK' AND type = ‘UQ')
BEGIN
ALTER TABLE Auction
WITH CHECK ADD CONSTRAINT Au_SK UNIQUE (name)
END
18. class AuctionApplication
class AuctionApplication
class AuctionApplication
( ( ( App
int id;
int id; int id;
void MethodA();
void MethodA();
string cacheTitle;
) void MethodB();
void MethodA();
) void MethodB();
) Source-controlled and
deployed scripts
V1 V2 V3 do not need to match! Revision History
CREATE CREATE CREATE dbo.Auction
TABLE dbo.Auction dbo.Auction
TABLE TABLE Logical In-
( ( ( Memory
id INT NOTid NOT NULL PRIMARY KEY, KEY,
id INT
NULL,INT NOT NULL PRIMARY Database
name VARCHAR(25) NOT NULL, NULL, NULL UNIQUE,
name VARCHAR(25) NOT
name VARCHAR(25) NOT
start DATETIME NULL, NULL, NULL,
start DATETIME
start DATETIME
len INT NULL NULL NULL
len INT
len INT
) ) )
19. CREATE CREATE CREATE dbo.Auction
TABLE dbo.Auction dbo.Auction
TABLE TABLE Logical In-
( ( ( Memory
id INT NOTid NOT NULL PRIMARY KEY, KEY,
id INT
NULL,INT NOT NULL PRIMARY Database
name VARCHAR(25) NOT NULL, NULL, NULL UNIQUE,
name VARCHAR(25) NOT
name VARCHAR(25) NOT
start DATETIME NULL, NULL, NULL,
start DATETIME
start DATETIME
len INT NULL NULL NULL
len INT
len INT
) ) )
V1 V2 V3 Revision History
New Incremental
Deployment CREATE TABLE dbo.Auction Deployment
ALTER TABLE dbo.Auction
(
WITH CHECK ADD CONSTRAINT
id INT NOT NULL PRIMARY KEY,
Au_SK UNIQUE (name)
name VARCHAR(25) NOT NULL UNIQUE,
start DATETIME NULL, V2
len INT NULL
)
20. Source Interpret,
Database analyze and
validate
Reverse engineer Schema Model
schema into DDL artifacts
Database Project
Build .dbschema
Schema Model file
DDL SQL Artifacts
Compose model representation
from source code fragments!
21. Target
.dbschema Database
file
Schema Model Schema Model
Model Diff Plan Executors
.SQL
Deployment
Additional schema artifacts Engine Incremental Target Update
22.
23.
24.
25.
26. Creating New Database Projects
Offline Schema Development
New Deployment
Schema Refactoring
Incremental Deployment
Schema & Data Comparison
27.
28.
29.
30.
31.
32.
33. Dependency Validation
TSQL Static Code Analysis
Test Data Generation
Database Unit Testing
TSQL Debugging
34.
35. TFS
Source Control
Check in to
DBDev
DBA
Staging
Database
Database Import schema Production
Project
Database
36. •Sync
Dev •Check-out
Env •Edit/Refactor
•Generate Test Data
•Database Unit Test
Dev •Check-in
Env TFS
•Work is being driven
Dev and tracked via work items
Env •Other team members can pick up
changes
DBDev
DBA
Staging
Database
TFS Shelving
allows DBA Dev
to provide guidance Env Production
and evaluate work Database
37. Daily
Test
Build Database
Output
Can also be TFS
used in a
“Continuous” Get Latest
build environment
DBDev Daily Build Test Lab
DBA
Staging
Database
Production
Database
42. Database Project Data-tier Application Project V1
(Mission Critical, Business Critical) (Departmental Apps)
Visual Studio Visual Studio
Build Build
Generate scripts .dbschema .dacpac
Deploy Deploy
SQL Server 2005, 2008, 2008 SQL Server 2008 R2 & 2008
R2 R2
43. DEVELOP DEPLOY MANAGE
SQL Server Management Studio
FinApp
1 Dev DB
Deploy / Reverse
Upgrade DAC Engineer DAC 2
SQL Server Management Studio
DBA
9
8
Visual Studio 2010 Manage, Register, Uninstall,
Extract, Upgrade DAC Control
Point
Create
policies DBA
7
3
Deploy /
Upgrade DAC
HR
Developer
Compile Hand-off to DBA
+ Build FinApp
Prod DB
6
5 .dacpac
SALES
Managed Instances
44.
45. SQL Server Version
DAC Feature 2000 2005 2008 2008 R2 Azure
Extract DAC Yes Yes Yes Yes Yes
Deploy DAC No No In SP2 Yes Yes
Delete DAC No No In SP2 Yes Yes
Register DAC No No In SP2 Yes Yes
Upgrade DAC No No In SP2 Yes No
SSMS Support No No No Yes Yes (2008 R2)
Databases are a critical component utilized by many (if not most) software applications. And yet, they are traditionally underserved by tools that can facilitate development, testing & deployment. Database developers are usually left to cobble together disconnected tools for developing & deploying database changes. Furthermore, database developers usually follow a process that is disconnected from the process followed by the application development team, resulting in an error-prone and labor-intensive system of collaboration. With VS2010, you can finally bring the process of managing changes to your database into the same toolset and process framework used by the other members of your software development team.
Databases are a critical component utilized by many (if not most) software applications. And yet, they are traditionally underserved by tools that can facilitate development, testing & deployment. Database developers are usually left to cobble together disconnected tools for developing & deploying database changes. Furthermore, database developers usually follow a process that is disconnected from the process followed by the application development team, resulting in an error-prone and labor-intensive system of collaboration. With VS2010, you can finally bring the process of managing changes to your database into the same toolset and process framework used by the other members of your software development team.
For those new to Visual Studio Database Projects, Database Projects provide 3 main pillars of functionality:1.) Managing ChangeVersioning of your database schema – Full fidelity offline schema development of your database within the project systemIncremental Deployment - Deploy your database schema against multiple versions of a database schemaSchema Compare – Database Tooling to compare schemas between databases, database projects, and dbschema (dbschema files which are the primary output artifact of building a database project) Schema Refactoring –Database Tooling to support common iterative changes to your database schema within the development cycle (Refactoring operations include: Expand Wildcards, Rename, Move Schema, Fully Expand Names 2.) Managing QualityDependency validation and visualization –Validation during design and build ensuring consistency and integrity of your database schema Static Code Analysis – Analogous to FxCop, but for SQL. The product has 14 rules that it ships with. The inbox rules cover naming, design, and performance issue categories. Unit Testing and Data Generation – A Unit Testing Framework similar to what is available to the app developer, but with T-SQL and Data Generation capabilities to test your instantiated schema with data.
3.) DDLC Integration into ALMTeam Developer brings the database development lifecycle into the Visual Studio Developer experience in a consistent and familiar manner. Many of the same idiom or metaphors now exist for database development that c#/vb.net developers are accustomed to. Database projects bring the data tier developer into the team based development lifecycle. (Define, Design, Develop, Test, Deploy, Manage) Lather, rinse, repeatBuild integration with MSBuild and TeamBuild4.) Database Development Platform ExtensibilityDatabase projects offer extensibility to add features to the project system or to expand features that ship with the productFeature extensibility includes: Custom Static Code Analysis Rules, Custom Unit Test Conditions, Custom Data Generators and Data Distributions, Custom Refactoring Types and Targets
Can you use a Diff Utility of any Version Control System to get the changes between V2 & V3 for the database ? No
Not performantError-prone because it’s difficult to get the dependency tracking correctLabor-IntensiveRequire extensive additional logic to account for customizations or versioning differences between different instances of production databases.Database changes must be made in a precise order to preserve the integrity of the schema & prevent data loss.Can introduce additional bugs
Visual Studio eliminates the need to ever hand-code database deployment scripts.
Schema Model = In-memory model of the database.Creating database objects & editing TSQL cause visual studio to perform background analysis of your changes & make the appropriate changes to the schema model, it may also detect syntax errors, dependency errors & thus protect the integrity of your database schema.As mentioned we persist our database schema as separate .sql scripts within a Visual Studio project system. Which is a physical container for grouping all of the .sql files that make up a database schemaBecause we are completely offline, and there is no database in place within the Database project system, we also need to understand the database from a logical perspective, namely how each of the object relate, depend on each other.We do that via a Schema Model, which is basically an in memory representation of that database schema as it would exist in a live database.To populate our schema model, we can take an existing database, reverse engineer the definition of that database (no data) and create .sql files for each schema objects(.sql file for each table, .sql file for each primary key, stored procedures etc.).We can then version control those .sql files just like you version control any of your .Net coding filesWith the .sql files, we then load the content of the file through our intrepret component to interpret the schema definition (is this a stored procedure we’re dealing with, or is this a table etc.) and then analyze the content(do we already have an object defined using this name, does this object depend on another object, namely for Primary Keys which table does this pk belong to etc.) and then we validate(is the object defined correctly, for Primary keys is the table defined and in an non error state). Once each of our objects pass this process, we then populate it into our schema model, which provides a true picture of a database which is fully validated and could be deployed to a live database without any semantic errors.The persistent model of the schema model is a .dbschema file
This is a simplified diagram of how the incremental deployment engine works. In a nutshell, it uses in memory models of the source and target databases to compare schemas to create a deployment plan. The deployment plan produced is dependency and data aware. Examples: Trying to DROP objects that have dependencies not in comprehended in the project will often fail the deployment.Modifying the schema of the database that may introduce data loss is optionally blocked in deployment. Test OK to lose data. Production, not so much. The deployment engine produces a list of differences and a deployment contributor acts on those differences to produce the least invasive approach to modify the target database to match that of the source. The deployment contributor combines this deployment plan with additional project artifacts and generates a SQL deployment script. Additional deployment contributors also act on the database target by emitting additional SQL or supporting artifacts LIKE a change list or data dictionary. We will see more of this later.
Now you can defer the comparison of the source & target database so that an appropriate script is generated based on the state of the target database.
The new SQL Server Utility provides an overall understanding of your organization’s SQL Server health as well as resource monitoring. The ideas originally came from consolidation projects and makes applications easier to move around.
Do Data-tier Application (DAC) projects replace Database projects? A lot of people are currently using database projects—initially, the adoption rate was slow, but it is definitely picking up. This table shows the strengths of each project type. Larger applications are best completed through Database projects. DAC projects add deployment intent and have been optimized for 1000 objects per project in V1. The aim of the DAC project type is to automate the process completely for departmental applications.
SSDT is the latest investment Microsoft is making in integrated tools for relational database developers targeting Microsoft SQL Server. SSDT is the evolution of Database Projects for Visual Studio, and contains new capabilities and improvements, all accessible within the Visual Studio 2010 Integrated Development Environment (IDE).