Database projects within visual studio

Editor's Notes

• #5: By utilizing the features provided by Database Projects, SQL Server Data Tools and the Data-tier Application Framework you can get one step closer to Database management nirvana.
• #6: Refactoring in SQL sucks. An intimate knowledge of the data structure is required before you can even think of refactoring Simple errors, like incorrect spelling of an object, are caught later in the development cycle then they should be, mostly at run-time Deploying/promoting a fresh database across environments – pretty much your best choice is the scripting route Applications are developed and released in versions. The database should always be in sync with the current production application, but what about the application version history? If you rollback to three versions ago for the application, is it that simple to do so for the database?
• #7: Buffered Declarative editing – Rather than focusing on how to enact a change on the database, database projects allow you to focus on what to do and the tooling takes care of the “how” for you. This declarative editing doesn’t just apply to database projects, this is applied to changes against a connected database as well. When making changes to a connected (or offline) database through the table or script designer your changes are buffered and validated against allowing you to see the errors before you make them Model-based design – A representation of the database that can then be validated against static code analysis and “compiled” to determine correctness Local testing and promotion – Using the LocalDB runtime you can test your changes locally and promote directly from the database project when you’re ready Source Control – Your applications are in source control, you can view history, compare between changesets, etc. Now you can do the same with database schemas SQL Unit Tests – Verify functionality with SQL Server Unit Tests. We’ll talk more on this later Scripts – Database projects let you create pre or post deployment scripts that are appended to your auto generated publish scripts allowing you to automate those tedious tasks of creating lookup tables, cleaning data from a table or the like. Pre-deployment scripts would be good for disabling SQL Agent jobs and the like Snapshots – At any point in the development of your database project you can create a snapshot of the project in the form of a DACPAC. You can use this to keep track of versions easily accessible outside of revision history, or to test upgrading to the current edition of your schema changes from SSMS Drift detection – This is more of an SSDT feature than a Database project, but when working against a connected database in the declarative fashion, schema changes can occur during your work. Before you get a chance to commit these changes to the database the tooling can detect drift and inform you that something has changed Comparisons – Again, more of a SSDT feature, but nonetheless useful. You can initiate a schema comparison between two different sources. The sources can be a database project, a SQL Server (or SQL Azure) instance, or a DACPAC. In the same vein, you can initiate a data comparison between two connected SQL instances
• #8: A database project is an offline Model representation of a database that any number of developers can pull down and start playing in their own sandbox without worrying about the repercussions of changing a live environment Offline – Similar to the Design-First approach of Entity Framework, you can design a complete database structure without an actual server Development – The standard approach for database development is called “Connected” development, meaning that all changes are committed against a live database either using the features of SSMS or now in Visual Studio with the SQL Server Object Explorer Project-based – With Database projects a DBA can create a development database from an existing production database and the development team can create an offline project and implement schema changes in the project without ever having to connect to a database Isolation – A database project allows for any number of developers to work against a database in isolation from one another. This allows them to focus on what they’re working on now and collaborate later T-SQL – One thing that I’ve always loved about Visual Studio is the rich support provided by IntelliSense, Goto Definition, Find All References and refactoring support, well now that is also available with T-SQL through a database project Scripts – After all the changes have been made in the declarative editor, the database needs to get updated somehow. Database projects will handle all the dirty work for you by generating the necessary scripts to upgrade your database Pre – Disabling Database triggers, jobs, etc Post – Those pesky lookup tables that your application is using as enumerator values, this is where you can enforce that those tables stay in the state you expect them. Refactor – Let’s say you want to rename a table on the database. Normally you’d have to manually do so to prevent data loss. However, if you’re using a database project and refactoring inside the project, you can rename a table and the automation script generation will be made aware of the rename and treat it as such. Otherwise, it would consist of a delete and create operation Verification – As you’re developing a database project, whether you’re using the table or script designers, you get on-the-fly validation against the “Model” of the database. Any verifications results against the model are then displayed in the Errors window (as well as hints in the scripts) where you can navigate directly to the issue Enforcement – Just like in the application development world where we want to enforce good coding standards and can do so through Code Analysis, the same can be done with T-SQL in a database project using the same Code Analysis tool
• #9: Create a database project from scratch, call it OrderEntry Create a table for Customers (CustomerId, CustomerName) Create a table for Orders (OrderId, CustomerId, ProductId, Quantity, OrderDate) Create a FK for Customer (in designer) Create a FK for Product (in script) Point out on-the-fly verification error on Product FK Create Product table (ProductId, ProductName), close tab Point out on-the-fly verification error has been corrected
• #10: SQL Server Object Explorer – Almost the exact same view available in SSMS now in Visual Studio, with some enhancements Static Code Analysis – Code Analysis settings can be configured per project and include things Microsoft considers best practice (such as not using SELECT *). Static Code Analysis can be configured to run on build of the database project, and in the case of Continuous Integration, prevent you from committing your changes to the trunk Table Designer – Same old table designer we’re all used to in SSMS, but again with enhancements. Including a multi-directional synchronization between Script, Design and Properties views Database Publishing – You can publish to a SQL Server or SQL Azure instance directly from Visual Studio, and register as a Data-tier application all in one. The flipside of this ability is also present in SSMS Language Services – As mentioned in a previous slide, SSDT gives you IntelliSense, Goto Definition, Find All References, and one-click refactoring capabilities Unit Testing – Who doesn’t love Unit tests? We have them in Managed languages such as C# and VB, why shouldn’t we have them in SQL? Although the method is a little different from a standard programming Unit Test, you still want to validate that your code works as expected. You can add SQL Unit tests to a standard Unit Test project in Visual Studio. As with standard unit tests, some setup must be done to prepare the environment for your tests. We’ll explore these (and a much quicker way of creating them) later SQL/CLR – Your .NET code for your SQL CLR references can now reside in the same project and will be compiled and handled accordingly by SSDT at time of compilation and/or deployment LocalDB – LocalDB comes as an optional install with SQL Server and a requirement? with SSDT. For those not familiar with LocalDB, it is a stand-alone, service-less, on-demand instance of SQL Server, much like SQL Express. For those interested, I recommend you dig deeper into it. It’s a very useful technology Schema Comparison – Schema comparisons give you the same type of visual difference detection that comes with Visual Studio. Data Comparison – SSDT does offer the ability to compare datasets between two SQL instances, but it’s not my product of choice for this task. But when you don’t have another option, this is free Buffered Declarative Editing – As mentioned before, SSDT lets you worry about the what, not the how when designing the database structure by taking a Model based approach Debugging – The same debugging experience that we have as application developers, and SSMS tried to emulate, you can achieve using debugging in a database project. Including the debugging windows: Locals, Autos, and Watch
• #11: Services – The Azure Database Import/Export service uses DACFx Tools include DacUnpack.exe and SqlPackage.exe etc DAC API – This API allows you to programmatically process DACPACs, BACPACs, manage Data-Tier Applications across multiple platforms and generate different types of scripts and reports
• #12: What you see here is the new features that the DAC Framework gives you. The bottom left of the picture here is where you’ll see Visual Studio in this cycle. Obviously the bottom right is SSMS using the DAC Framework
• #13: DACPACs are created using standard XML formatting and can be unpacked using the DacUnpack.exe utility included with SSDT DACPACs contain schema changes only – BACPACs contain schema and data (serialized into JSON) and are primarily used to copy databases between servers Utilizing the DAC properties (primarily version info) application and database developers can push a very specific changeset to both the application and database production environments
• #14: Scenario 1 – We have an existing database and we need to get it under control by using Database projects Navigate to AdventureWorks on LocalDB in SQL Server Object Explorer Right-click database and Create Project… (call out that this is just one way to accomplish this) After database project is created, right-click on project and select “Import Project…” and show that this is the other method of creating a database project Scenario 2 – Now that we have a database project to manage changes we want to test these changes locally Close solution and open existing AdventureWorks solution (to simplify LocalDB incompatibilities) and call this out Update dbo.ufnGetDocumentStatusText to add a fourth valid status – 4, Rejected Press F5 to deploy these changes to LocalDB Show how LocalDB and VS database projects play nice together by creating a “Projects” sandbox in LocalDB so you know exactly where your compiled database projects reside Set a breakpoint in the function and kick it off using a new query window, using “Execute with Debugger” Demonstrate the Debugging tools available Scenario 3 – SQL Unit tests Add a basic Unit Test Project to the solution Manually create a unit test for dbo.ufnGetDocumentStatusText and point out that although this is possible, it is exceedingly tedious Add a new Sql Unit Test – call it ufnGetDocumentStatusText_Manual Create the necessary script as it calls out, rename the script to TestRejected Provide SELECT [dbo].[ufnGetDocumentStatusText](4); as the test body Add a new “Scalar Value” test condition and remove the existing Inconclusive test condition Set the properties on the condition to expect Rejected and run the unit test Use SQL Server Object Explorer to create Unit tests from sprocs and functions Find the function in the SQL Server Object Explorer under “Projects – AdventureWorks” Name the test class “ufnGetDocumentStatusText_Easy” Repeat steps above Show other test script types – (Common Scripts) and describe use-case for Test Initialize and Test Cleanup scripts; ditto for individual test scripts Common scripts (global to all tests in said unit test) Individual are not global Show Code Analysis options in Project properties and kick-off code analysis on solution to show Static Code Analysis support for T-SQL Scenario 4 – Our changes worked, now we want to promote the database changes to Azure and push the changes back to SQL Change the platform target to Azure in the project and show the other SQL Server versions, note the errors Change platform target back to SQL 2012 Demonstrate each different method of promotion Schema compare – Open a schema compare between the project and original database (localdb)\Demos – AdventureWorks2012 Publish – Right-click on the database project and select publish Set connection string to schema compare target and call out that publish profiles can be saved to the project; mention the “Register as a Data-tier Application” checkbox and mention that the DAC properties in the Database project are used for the DAC properties on SQL Server Snapshot – Create a snapshot of the database project Open SSMS, connect to (localdb)\Demos and show the different DAC options Upgrade – On an existing database you can choose to Upgrade a DAC (even if the database is not registered as a DAC) If the database is registered as a DAC, you get detailed drift detection during the upgrade process Deploy – Without an existing database to upgrade you can deploy a fresh instance of a DAC Show DAC options in VS Publish – On the SQL Server Object Explorer you can publish to an existing database or a new one directly from VS Publish to SQL Azure from VS Project Azure SQL info: Connection string - qk8jjsgmda.database.windows.net,1433
• #15: DACFx & DACPAC – Utilizing DACFx and DACPACs snapshots of a database model’s structure can be retained for version history in source control DACPACs can simplify the coordination of deployment in production environments SSDT – With the tooling provided by SSDT an application developer can experience rich language support for T-SQL and design necessary database structures all inside Visual Studio, leaving the more advanced database management responsibilities to the DBAs using SSMS Collaboration – Since all changes are in Source control, multiple teams can work on the same database project (focusing on their Isolated portion of the database) with reduced fear of toe-stepping or overriding a change committed by another developer in a different team DAC – Utilizing the DAC properties available, each database can be treated like a 1st class citizen in the scope of the application rather than just an resource