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