Download presentation
1
SSDT Database Projects from the ground up
2
Declarative Database Development with SSDT
3
Who he/me? Jamie Thomson SQL Server freelancer Blog at Tweet
4
Agenda for today SSDT Positioning SSDT IDE tour
Connected database development Declarative, offline database development & Localdb Publishing Continuous Integration (CI) and Continuous Deployment for SSDT projects
5
Agenda for today (2) Data Publishing Feature deep dive Refactoring
Database Unit Testing References & Composite projects Tips from the field
6
Please don’t wait to ask questions… …I might be asking you some!
7
Positioning Or, why this thing exists?
8
Positioning : Naming confusion
9
Positioning : Naming confusion (2)
Later Janet says: “In the SQL Server box, the SSDT shell includes former BIDS projects. In the web acquision experience, however, the SSDT shell only includes the database projects component. It is accurate to say that for for web install scenarios, SSDT refers to only database projects. We recognize that our messaging on what SSDT is has been confusing and even contradictory and we're working on getting a cleaner story in the future.”
10
Positioning: What is SSDT?
...provides an integrated environment for database developers to carry out all their database design work for any SQL Server platform (both on and off premise) within Visual Studio. ...provides an integrated environment for database developers to carry out all their database design work for any SQL Server platform (both on and off premise) within Visual Studio.
11
SSDT Heritage First released in 2005 as Team System for Database Professionals Required a separate license Later Visual Studio Database Projects With Visual Studio 2010 Pro Colloquially known as: Datadude DB Pro
12
SQL Server Database Project SQL Server Connected Development
SQL Server Data Tools SQL Server Database Project SQL Server Connected Development SQL Server Object Explorer SQL Static Code Analysis Database Publishing T-SQL Language Services Buffered Declarative Editing Unit Testing Table Designer Schema Comparison Local database runtime (aka LocalDB) SQL CLR T-SQL Debugging
13
Foundation of SSDT Declarative, model-based database development
Integrated tools with modern language services Connected and offline with local testing Target SQL Server and SQL Azure Detecting and managing database drift Application development integration …and free!
14
Any other options? Redgate SQL Compare SQL Data Compare SQL Prompt
SQL Source Control SQL Test SQL Doc And more…
15
Much more in here. Consult Gert’s video/slides (which I’ve pasted into OneNote)
16
Connected Database Development
17
Connected database development
New for SSDT over previous incarnations SQL Server Object Explorer (SSOX) Rich T-SQL editing Intellisense Update previews Stored procedure debugging Code-behind table designer View/Edit/Script data Demo an attempted update to a table that would break something else – SSDT will prevent it Insert snippet (CTRL+K, CTRL+X)
18
SSMS vs SQL Server Object Explorer (SSOX)
19
Intellisense
20
Snippets
21
Update previews Changed the name of a PK
Show Data Tools Operations window
22
Stored Proc debugging
23
Data Viewing/Scripting
Choose number of rows Script the data
24
Demo Connected Development using SSDT
Open sproc [PutETLJob] Change name of a table - show warning appear Change parameter name - show error appear Change a keyword - show errors New sproc - show intellisense Demo an attempted update to a table that would break something else – SSDT will prevent it Insert snippet (CTRL+K, CTRL+X) / SSOX: New Object… Insert Snippet Debug
25
LocalDB
26
LocalDB SQL Server Express LocalDB free uses sqlservr.exe
Its like SQL Server Express…. uses sqlservr.exe same client APIs small production DBs compatible with other editions connect from SSMS same limits Like SQL Express: Proper name -> SQL Express LocalDB Free Can be used for small prod DBs sqlservr.exe same client APIs (ADO.Net, ODBC, etc…) Connect from SSMS Same limits (10GB DBs, 1GB RAM, 1 CPU But different: No upgrade to other editions (Express can be upgraded using a license key) Compatible with other editions Requires no management - devs don’t need to be DBAs No multiple instances (tho each Windows user can have their own), but does have multiple processes No service no edition upgrade no service …but different! no multiple instances no management
27
Sounds like SQL Server Compact, right?
Not really! Compact is a DLL that runs in-proc, LocalDB is a separate process Compact is feature-less in comparison. No stored procs, less data types
28
LocalDB Connection String
Data Source=(localdb)\v11.0;Integrated Security=true
29
sqllocaldb.exe Command-line “management” tool for localdb
List instances List versions Toggle tracing Create, Start, stop, delete instances
30
sqllocaldb.exe – list instances
sqllocaldb.exe info
31
sqllocaldb.exe –instances info
sqllocaldb.exe info “v11.0”
32
Declarative Database Development
33
The problems of “living databases”
Databases evolve New objects are required Existing objects must be modified Databases are inherently stateful It’s the data, stupid! No “rip and replace” DROPping stuff How do we safely DROP? Database Drift “What’s this in my DB?” Reverse engineering those changes Database drift example: Someone creates an index with same definition but different name -> could lead to two identical indexes
34
Lots more code!!! Object name repeated Dependency Initial state
Not the true state of the table Initial state Lots more code!!! State transition State transition Inconsistent existence check
35
Other schema changes to consider: Renaming columns
Consider affect on dependent objects Changing column data type Changing column order in an index Schema-bound views Indexed views
36
“The deployment black hole”
Deployment time increases Deployments are not cumulative e.g. To deploy version x, first need to deploy version x-1, x-2, etc… Patches get “lost” BizLogic code dev time : Deploy code dev time Deployment maintenance becomes a full-time job As code increases, so do the bugs Orphaned objects State transitions are true when coded, may not be later
37
Some indisputable truths
Database state is not 100% certain Unexpected data Unknown schema changes Previous failed deployments may have left detritus You cannot check for all permutations… …you cannot know what changes others have made that conflict with yours… ….thus coding state transitions is ultimately futile!
38
The declarative method
Describe what you want your schema to be, not how to get there
39
RestartFramework demo database
RestartFramework Provides restartability for SSIS packages Open Source (via Codeplex) Incorporates a SQL Server database Defines “work” to be done by an ETL process Captures work history Database is managed using SSDT
40
RestartFramework demo database
41
Demo Declarative Development using SSDT
Import DB Build/Deploy Build/Deploy again (minimal changes) Add a new object
42
What did we just see? Import database
Build/deploy a DB project to create a new database Build/deploy again. Observe changes. Minimal changes Less “work” No “state transition” code Add a new object. Build/deploy again. Only the new object gets created What sorcery is this? Let’s explain!
43
Start with a model A model…
describes every object in your schema is “what you want your schema to be” is an offline representation of your database schema Can be in an inconsistent/incomplete state In SSDT models, objects are modelled using T-SQL
44
Building the model Parse the source code Interpretation
Check syntax Transform into programmatically accessible representation Remove comments where appropriate Interpretation Wire up dependencies Validation rules Semantic checks e.g. objects with INSTEAD OF triggers cannot be used in transactional replication Code Analysis Further rules to be enforced (Code analysis is optional)
45
Storing the model Stored in a .dacpac file Actually a Zip file
46
Inside a .dacpac Open Package Convention (OPC) format
“The Open Packaging Conventions (OPC) is a container-file technology initially created by Microsoft to store a combination of XML and non-XML files that together form a single entity”
47
Inside the model
48
Go and crack open the built .dacpac file – show that it’s a zip file.
Open up Model.xml and look into it.
49
Deploy a .dacpac Load the source .dacpac file into the deployment engine Produce a .dacpac file from the target, load it into the deployment engine Compare the models, taking refactor log into account From difference list, produce list of changes in dependency order Generate deployment script (.sql file) Optionally execute the deployment script
50
Deploy a .dacpac
51
Idempotency An idempotent operation – produces the same result no matter how many times the operation is applied Multiply by one, Add zero SSDT Deployment is idempotent
52
Offline Development
53
Why work offline? Sandbox
Protect ourselves against making changes to production database Working with code, not objects Better integration with source control
54
Offline development Not writing code against a database
Big paradigm change Different to SSMS Always working against the model Features Intellisense Real-time syntax checking Real-time dependency checking
55
Offline development Advantages Know of errors early and often
No server required No resource sharing Working with code, not database objects Easy integration with source control Changes by multiple developers can be merged Promotes “sandboxing”
56
Demo Offline Development using SSDT
Open sproc [PutETLJob] Change name of a table - show warning appear Change parameter name - show error appear Change a keyword - show errors New sproc - show intellisense
57
What did we just see? Incorrect table name creates warnings
58
What did we just see? Incorrect parameter name creates error
59
What did we just see? Incorrect syntax creates error
60
What did we just see? Intellisense
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.