I’ve had the pleasure of using SQL Server Database Projects that come with SQL Server Data Tools in my latest project and I’ve really come to like them. Let me take you on a little tour to tell you why.
Reason #1: They solve the database version control problem
Putting your database into version control has traditionally been a bit of a challenge. In past projects, I’ve taken several approaches, from scripting every change and having a massive rolling upgrade script that just keeps growing with every change, to using third party tools like Red Gate SQL Source Control. The former approach was labor-intensive and required some SQL expertise, which left only a few developers qualified to maintain it. The latter tool was more junior-friendly but suffered from a variety of bugs (migration script reliability, faulty script parsing, deployment awkwardness). Database projects offer the best solution I’ve worked with so far. They still have their weaknesses and limitations, but the sum of their strengths and weaknesses still exceed those of the other two approaches mentioned. When you create a Database Project and point it at an existing database, it will import all objects into SQL files, one per object, and organized into folders by their type. Being simple text files, they are easy to version and compare.
Reason #2: They validate your schema and make navigation a breeze
Have you ever wanted to change something in your database, but hesitated with your fingers hanging anxiously over the keyboard as you try to remember everywhere this thing might be referenced? Database projects help reduce that anxiety in two ways. Firstly, database projects have some intelligence built into them and will detect most invalid references automatically. I say “most” because I have experienced situations where the database project reports no errors, but an error occurs during deployment because of an undetected invalid reference. I haven’t been able to detect a pattern yet that reliably causes this to occur. However, that brings me to the second way that database projects can help, which is simply that all of your database code is contained in a Visual Studio project, so you can use familiar search & replace tools to search the text of all your database objects. It is possible to do this within SQL Server itself, but requires you to write a little custom code. I’m quite comfortable with the homegrown workflow that I’ve developed to work entirely within SSMS, but even so, being able to pop open DPack File Browser with alt+u, type a few letters of a procedure name and press Enter to open it is much more ergonomic.
Reason #3: They make it easy to test your database
Database projects / Data Tools let you add database “unit tests” to a new or existing test project. Now of course they’re technically not really unit tests because they’re running in .NET but have a database dependency. But honestly, I don’t care about this distinction because the value of tests are in having an automated verification of correctness, and that’s what’s exciting about them. You can always put the database tests into their own test playlist and only run them occasionally if their relative slowness becomes problematic. When you create a database test, you get a designer that lets you edit some SQL that runs the test and outputs results, then a pane that lets you define test conditions that operate on the results returned by the SQL of the test. You can test on the following conditions:
- Data Checksum
- Empty ResultSet
- Execution Time
- Expected Schema
- Not Empy ResultSet
- Row Count
- Scalar Value (with absolute row & column offset)
Some of these tests are not too exciting because you could test them yourself in pure SQL, but others are kind of interesting. And the fact that they all run within the VS test runner is quite nice. One that is especially interesting for getting legacy systems under test is the first one, “Data Checksum”. This test is useful because it lets you establish a baseline result very simply, and then get alerted any time you make a system change that causes that original baseline to change. This ability to quickly and easily test for change from a baseline increases confidence to clean and improve a legacy system, secure in the knowledge that you will know as soon as you break something.
Reason #4: They make deployment of changes easy
This is one place where I think database projects did a way better job than Red Gate SQL Source Control in particular. With the latter, you must have SQL Source Control installed on a system that can connect to both the source control repository and to the production database. Such a configuration is not always possible or realistic, and their offline/disconnected scenarios are awkward in my estimation. In comparison, database projects have much better support for updating a database that is inaccessible from the development environment. Here are all the ways you can deploy changes to a database from a database project:
- Perform a schema comparison and select which changes to apply to the DB and/or which ones to apply to the project. This requires connectivity from VS to the target DB.
- Create a publish profile and publish all of the database project’s changes to a target database from VS. This also requires connectivity form VS to the target DB, but once configured, requires fewer steps than the first approach.
- When you build a database project, it outputs a .dacpac file which contains a description of the desired schema to migrate to. This file stands alone and can be applied to a production database without the use of VS in two ways:
- Interactively, by right-clicking a database in SSMS Object Explorer and choosing the obscurely-named “Upgrade Data-Tier Application” menu item under Tasks. This approach has some limitations and offers fewer options, but can be more approachable than the next option.
- Command-line deployment with SqlPackage.exe. This approach has a few advantages, such as increased flexibility and options, and of course the ability to script database change deployments.
With all these options, you should be able to find one or more that will fit your development and deployment needs.
One weakness
The one weakness that I’ve seen with Database Projects (or really, the Data-Tier Applications that they output) are in their data migration support. They support one pre-deploy and one post-deploy script, and it is up to you to detect the state of the database and whether or not to execute any particular data migration. While Red Gate SQL Source Control’s migrations never worked well for me, I liked the concept of small, transitory migration scripts that only got loaded and executed when needed. However, I am comfortable with writing SQL to detect the state of my database, so this weakness is not a huge negative for me.
Overall, I really like all of the features offered by SQL Database Projects and you can’t beat the price (free)! I would recommend the use of SQL Server Data Tools to any developer who is working on an application that accesses a database.
The post The Joy of SQL Server Database Projects appeared first on Falafel Software Blog.