It’s a fairly easy concept to understand, and it does have a nice design time feeling letting you feel in full control of what is actually going to happen to the schema when these changes are deployed.

It can have some challenges though, especially as a code base ages.

• Long lists of migrations
• Artifacts describing tables that no longer exist
• Migrations being misused as “run something once” completely unrelated to sql schema
• Drift between the actual database, and the result of running migrations from scratch (someone made a direct change in SQL to fix a prod issue)

I’m sure there are more, and yes, as always, these come down to not having the perfect process. But we’re all human (for now).

Still, it made me wonder if there was a different way to approach this. Then I saw a talk by Erik Ejlskov Jensen introducing me to a different set of tools for MsSQL/SQL Server.

Enter the Sql Project

Using Microsofts own Sql Project, or the OSS MSBuild.Sdk.SqlProj takes a different approach.

You define, in SQL, how you would like the database schema to look, and then you use the tooling when deploying to compare the desired state, to the current state of the target DB, and it will tell you what needs to change, and apply those changes.

A few reasons why I like this approach:

More coherent file structure

For each table (and other objects), you will have a single MyTable.sql file, that contains the desired design for that table. This means it’s easy to see the full schema for it, and it’s easy to track historic changes to it via git.

I also prefer this over EF Code First migrations, where it is less obvoius how you need to design your model, to make the table exactly how you want it.

This is just native SQL.

-- MyTable.sql
CREATE TABLE MyTable
(
    Foo CHAR (10) NOT NULL,
    Bar VARCHAR (50) NOT NULL
);

Drift detection

Using the tooling for SQL server in your deployment process, you can easily get warnings if the target database contains objects that your desired state does not. And if applying those changes would destroy data.

The tools can both generate a report of what changes are detected, and a SQL script to execute them that you can then review before applying.

Analyzers for good practices

Using the MSBuild.Sdk.SqlProj style project, you can take advantage of a large set of analyzers that will let you know if you are making some typical mistakes that could hurt your database design.

It can also tell you if you are not following the naming schemes, and lots of nice reminders like that.

This is typically something that migrations do not give you, because they might only compile to SQL at runtime.

Should you use it?

If you are seeing some of the issues I mentioned with traditional migration processes, this might be worth a look.

I don’t know if MySQL and PostgreSQL have similar tooling options, but I imaging that companies like RedGate offer tools that acheive the same effect.

I found it much cleaner to just declare the desired state, and rely on good tools to apply them, over managing a changelog of diffs.

The first programming I ever did as a kid was learning Turbo Pascal with the kid next door, whose dad taught us. It was mainly getting the speaker to go beep, and printing funny words on the matrix printer.

Next I borrowed one of those C64 books with full code for a small game. After typing for hours, I was gutted that there were no graphics. That was the end of programming for a while.

Starting my 20’s I was actually aiming for a music career, but to get going I needed a website. So I started learning to make websites, and got a bit of education. I though I would be an entrepreneur, but turns out that is not what I actually enjoyed. It was the learning.

Tinkering with a problem, and figuring out how things work. That was the real joy.

So I got a web dev job. And it was a lot of this:

$(".that-button").click()

Building a bunch of websites I had no interest in, but it allowed me to learn stuff while building them. An that has basically been the same since. Building things for others, with the payoff that part of the job is picking something apart, and see what makes it tick.

That balance appears to be in danger, thanks to recent developments in the imitation machines. “Don’t spend time learning that, just make the machine learn it, and then ask how to do it”.

That is like watching someone else learning to play the guitar.

So I fear that if the current trend continues, there will be no joy left for me in my current profession. Which then begs the question: Where do we go from here?

I have no answer to that. It is still going to be around 20 more years before I can retire. So if I could spend 20 years getting to here in software, could I spend the next 20 doing something completely different? What would that even be?

Maybe the bubble will burst, and some sanity will return to the world. Or maybe we will never speak to an actual human again, because that is just too inefficient.