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?
Category: Editorial
-
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.
-
Location Data Is Not Anonymous
We are truly in the era of big brother and 1984, where any of us can be tracked if we use a mobile device. That’s a scary thought and one that many people might not like. There are plenty of people in management that want to increase revenue or profits from the use of data, even if we might think their decisions are unethical or immoral. When there’s money to be made, often they ignore other issues.
There was a post from Bruce Schneier earlier this summer that noted various public data, some sold by brokers, was used to track location and usage of a device by de-anonymizing aggregated data. The post ends with these statements:
“Location data is not anonymous. It cannot be made anonymous. I hope stories like these will teach people that.”
That’s a somewhat scary thought. While I like knowing where my loved ones are, I’m not sure I want any random person to be able to track me with public information. Unfortunately, that is unlikely to be the case in the future. Lots of the data we have rarely worried about being public is much easier to access when records become available digitally to anyone. They ability to work with large amounts of data allows anyone with a connection to gather information that might be used in ways we never imagined.
For me, public records of property at the most annoying, as I constantly get unsolicited real estate offers to buy houses. For others, there could be concerns about safety, stalking, or other nefarious purposes. Swatting and other forms of harassment are far too common in the modern world.
While many might see the GDPR, and similar laws, as too restrictive for businesses and government, I think privacy is more important than ever. We ought to have more strict regulation on the use of data about humans, and force companies to obtain consent, allow it to be revoked, and be forced to properly manage and secure our data.
This doesn’t just apply to location data, but any data about humans. I hope the future becomes a place where we globally consider digital privacy a human right.
Steve Jones
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
