Voice of the DBA

Category: Editorial

  • Republish: The Digital Twin

    Hopefully I’m in the UK today, and I’m cleared to travel. This is time in the office and some recording for the PASS Data Platform Community Summit, so you get a republish of The Digital Twin.

  • Republish: Who’s Smarter? Humans or AI Systems?

    I’m in Belgium today, at the Data Minds Connect conference. As a result, I’m re-running Who’s Smarter? Humans or AI Systems?

  • The Last SQL Server Service Pack

    I wrote The Last Service Pack a few years ago, thinking that SQL Server 2016 SP2 might end all large updates. At the time, Microsoft was moving to a Cumulative Update process, with the aim of releasing small patches for each version every couple of months. They’ve done a good job of that, and SQL Server 2017 now has CU 26 with more coming.

    With little fanfare, we got Service Pack 3 for SQL Server 2016 recently, with a long list of fixes.  Even Pedro Lopes notes this is the final service pack for any version. That means I expect that in the next few years, I’ll start to encounter people working with technology who have no idea what a service pack is or what those are used for.

    Visual Studio has “updates”. VS Code and ADS just tell you constantly they need an update, with no deal designation about versions. SSMS has slowed their pace of changes, but the tool really just gets a new version every few months. With Windows we get a large update periodically, but those seem to be called a May 2021 update (or something similar).

    I wonder if we are moving towards the era of commercial software being continuous, with updates being released continuously and available for install by customers. Certainly this is the way many of us build software inside organizations, constantly enhancing and fixing code and deploying it out. We often don’t give our customers much choice in whether we deploy changes, and I suspect commercial software is going this way in many instances.

    I not-so-fondly remember digging into Service Pack changes and trying to test them against applications, sometimes for weeks before a deployment across an estate. These days, I tend to apply cumulative updates a few weeks late, after ensuring I don’t see many reports of issues on the Internet. I don’t mind keeping up to date, but I don’t like to be the first one to do so.

    I don’t know that I care if Service Packs go away. I’ve gotten comfortable with Windows updates, Cumulative updates, and even the random changes in VSCode/ADS that seem to come monthly. I don’t see applications crashing often enough to stop trusting most vendors. Hopefully that feeling continues.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Choosing State Over Migrations

    I ran across an article about state v migration based development for Snowflake. While I think that this article is a bit slanted because the author is building a tool, it does present some good reasons why people worry about migration-based approaches. This article also references a work from Alex Yates on the two approaches.

    Everything we do in relational databases, and in some other platforms like Snowflake, is a migration script. If you run SQL Compare and get the differences, you are generating a migration script. It might contain lots of changes, but it’s still a migration script. I wish I could write CREATE OR ALTER TABLE scripts, but that’s not a part of the SQL specification (yet).

    The concerns in the article are valid, though some are a bit outdated. I know that I am biased a bit as my employer, Redgate Software, sells tools in this area. However, over the years, we’ve supported and worked on both approaches. We do a lot of research, and I get to provide feedback on the good and bad of how we approach the problem. Ultimately, I think the world is very chaotic and we should be as flexible as possible with developers.

    I find that most developers like the state approach. Even if they want to write code themselves, having an easy way to capture the state of objects and keep track of them is useful. When we see a table difference, we want to see a view of the old table and new table in a CREATE TABLE statement: the state approach.

    For deployments, we always need migration scripts, but we want to build them as appropriate for the situation. Cherry-picking out specific changes is often what we need when urgent hot fixes need to be deployed, or a piece of work isn’t tested. In those cases, we might need to deploy some changes and not others, which often require us to put a subset of changes into a migration script(s). That’s a hassle, and these situations are often where we find humans making mistakes.

    Ultimately I prefer state sometimes and migrations others. If I had to pick only one, it would be migrations, but I’d ensure I had a state view of the schema using a tool like SQL Compare. I want to be able to see history and capture changes. in a human-readable format.

    One approach isn’t better, and both have advantages and disadvantages. We are often under pressure to be more like DevOps software developers, adaptive and agile. We can use either state or migrations to do this. The important thing is that your whole team understands the approach we are using and the potential limitations. They also need to work together to smooth out your database deployments.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.