A Fine Slice Of SQL Server
Deb Melkin is looking forward to a pair of features:
When I look at this release, I feel like I’ve been more tuned into what’s coming out than any other. I’m still not sure how that happened. But I think overall it’s a good thing because there really is a lot being packed into this release. If you’re just trying to figure out now, you’re already behind.
There are really 2 features that I’m really excited about:
Read on to learn more about both of them.
Leave a CommentSteve Jones notes one interesting change to backups in SQL Server 2025:
I’ve been a DBA (or Ops manager) for quite a bit of my career, and one of the things I’ve thought was top priority was backups. I always want to be sure I have a recovery strategy, because if I don’t, nothing matters. Things go wrong and systems fail and I need to protect systems.
Security is a close second, but backups really matter.
Something else backup-related that Steve doesn’t mention is the new form of backup compression using ZSTD. Initial testing of this has been fairly positive and I think it’s worth trying it out as well.
Leave a CommentChad Callihan is excited about a limitation:
I had written most of this blog post before seeing this month’s T-SQL Tuesday invite. I decided to hold off a few days to post because, while it’s no secret, I think it’s worth pointing out to those that may not know: before you spend time testing SQL Server 2025, make sure you consider what version of Developer Edition to use.
You may read that and ask, “What do you mean? Isn’t there only one Developer Edition?” That used to be the case, but not anymore.
Read on to see why this is important for a large number of companies.
Leave a CommentHowever, SQL Server 2025 does bring some great options for doing fuzzy string matches, making custom Data Quality options even richer. I’ve spoken about this at some user groups recently (including tomorrow, remotely for TriPASS, and in a few weeks in Melbourne and Sydney for Difinity), and in that session I go much deeper into how I see data matching going. I’ll also write more about these methods in future posts, but it’ll take a few posts, covering quite a few sub-topics.
If you want to see that session, our user group (the Triangle Area SQL Server Users Group) is hosting it Wednesday morning Australia time, or this evening US Eastern Standard Time.
Leave a CommentSteve Jones says better late than never:
I hosted this month, late as it turns out, but we still had a few entries. Here’s a look at the blogs people published.
Read on for links to the half-dozen entrants this month, who talked about string parsing in SQL Server.
Comments closedLucas Kartawidjaja gives us a blast from the past:
When dealing with data inside SQL Server, especially when it’s delimited by a clear separator character, earlier versions (before SQL Server 2016) required us to write custom parsing functions—either as T-SQL user-defined functions or CLR functions. Starting with SQL Server 2016, we can use the built-in STRING_SPLIT() function to handle most of these tasks.
However, more often than not, we need to parse data that resides outside SQL Server—for example, in log files, CSV data, or other data sources. For these cases, I often use Microsoft Log Parser, a free command-line tool available here.
Click through for a demonstration of how it works. Or a reminder, if you’ve been in the business for a long long time.
Comments closedCourtney Woolum splits a string:
If you’ve escaped string parsing thus far, count thyself lucky. I’ve seen some numbing scripts from pre-SQL Server 2016 when STRING_SPLIT was introduced. I think the fact this month’s T-SQL Tuesday is entirely on string parsing says enough about how many ways there are to paint this particular cat.
In the post, Courtney mentions learning early on to avoid using the APPLY operator. I want to have harsh words with whoever taught her that. Purposefully avoiding the APPLY operator artificially hamstrings your ability to write effective T-SQL code.
Comments closedHugo Kornelis prefers surrogate keys:
I am currently most known for my performance tuning and execution plan work. But when I started working with database, I actually came from a background of data modelling, database design, and normalization. And that has never fully left me. In fact, I have in the past two years created a whole series of YouTube videos about database design and normalization. And a much longer time ago, I recorded a Pluralsight course on this topic that is still available for viewing.
One of the very basics of schema design for a relational database is to store atomic values in every column. One column, one value, no more, no less. That automatically rules out all repeating groups. So a single column to list all my email addresses? Sorry. You are doing it wrong. And you will pay the price when you try to protect the integrity of your data. Or even just report on it.
I wanted to copy this second paragraph because CJ Date, in his book Database Design and Relational Theory (2nd edition), issues a mea culpa around repeating groups, stating that it’s best to ignore his prior arguments on the topic. Though in Date’s case, he specifies a repeating group as something like { Name, Email1, Email2, Email3, … } rather than a delimited list.
But even composite items can be in 1st normal form. For example, a US telephone number has a country code (+1), an area code, an exchange, and a four-digit number, followed potentially by an extension. The name “Bob” is an array of characters, and each array of characters is a composite of bits forming 1-4 bytes depending on collation and other details. At the end of the day, first normal form is about the shape of the tuple (a heading exists with a known set of names and data types; all tuples follow the same header; no duplicate tuples are allowed; attribute and tuple order does not matter for operations; and all attributes are regular inasmuch as they have names, data types, are not hidden, etc.).
At the end of the day, what Hugo is saying is good practice: if you have a business need to identify segments of an attribute separately, then it makes sense for each segment to be an attribute on its own. But because there is no solid mathematical property that explains exactly what an attribute is, and because database normalization is ultimately a series of mathematical formulations, we cannot use normalization as the reason to keep or separate the contents of an attribute. Thankfully, there is more to database design than normalization alone (and thankfully, database normalization itself is such a robust field that provides good advice that people should follow).
Comments closedAndy Brownsword digs into a nice capability around using regular expressions:
Now that we’re on the cusp of adoption within SQL Server, it’ll be a valuable tool there too. However, after trying it out last week, one omission stood out – one of my favourite features for string parsing: Named Groups.
Where a usual expression can be used to match a string, Named Groups can also be used to extract details from the string. Using an example from Steve’s invitation where a PO number
20260720321433begins with a year/month and then a number, this could be split with named groups:
Andy mentions the community displeasure for CLR and that displeasure annoys me to no end. I think 90% of the hysteria around CLR in SQL Server was a misunderstanding in terms and unwillingness to learn other programming languages. If you ever catch me in person, I’ll rant about it at length.
Comments closedLouis Davidson goes looking for list items:
From the title of “Favorite String Parsing”, I will say 100% it is using SQL Server 2025’s addition of Regular Expressions. Previously, parsing text in SQL Server was one of my least favorite things to do. Regular expressions will make it just a bit nicer, because it has a lot more power than
SUBSTRING,LEFT,RIGHT, andCHARINDEX/PATINDEX. All generally “good enough” functions for a lot of the things you need to do, but often woefully inadequate for parsing large amounts of text.
Yeah, T-SQL RegEx is definitely a nicer approach, though HTML doesn’t have to follow the consistency rules of XML due to browsers being very forgiving in their interpretation of the language, so it’s easy to get tangled up trying to parse websites.
Comments closed