Press "Enter" to skip to content

Curated SQL Posts

Red Flags in Database Code

Tom Zika has a list and starts with AI-generated code:

This one didn’t exist three years ago. Now it’s the first thing I look for.

To be clear, I’m not anti-AI. If the AI wrote clean code, I probably wouldn’t even notice. The red flag isn’t that AI generated it – it’s the patterns that give it away. I recently saw a real case where someone needed to update a set of values. Simple enough, right? Here’s what the AI-generated solution did:

Click through for a laugh, as well as several other red flags.

Leave a Comment

When All Joins are Left

Hugo Kornelis gives an example of a red flag:

This anniversary edition is hosted by Brent Ozar. And his chose topic is: query red flags. Things that make you groan when you open a query and see them in the code. I’m sure there will be a ton of posts, because there are so many. I myself could probably fill a book with things I consider a red flag (and someone else would then point out that my queries have things that they consider red flags, but that is another discussion).

But let’s focus on just one thing in this post.

Hugo selects the case when all query joins are LEFT OUTER joins. Especially when the logic of the query mandates INNER joins.

Meanwhile, if all of your query joins are RIGHT OUTER joins, you’re just chaotic evil.

Leave a Comment

The Siren Song of Code Reusability in SQL Server

Reitse Eskens hits on a long-standing pain point in SQL Server:

In an effort to make code reusable, someone decided to use Scalar User-Defined Functions. About ten of them. And each function was called in the SELECT list of each query sent to the database.

The worst part is, the instincts behind doing something like this are perfectly reasonable. In most programming languages, composing functions or refactoring code into isolated functions that you call is so cheap as to be (almost) free. But in T-SQL, that is rarely the case.

Leave a Comment

Starting Points for Query Tuning

Deborah Melkin shares some tips:

This one is really timely for me as I just started a new job. Performance tuning was part of the interview process so I’m really excited to dive back into doing more of that day-to-day. In fact, I just got added to the email reports with the top SQL results for the worst performers. Here’s some of what I’ll start looking at in that list and why:

Click through for Deborah’s red flag list. Of note, a red flag is not necessarily a bad thing. But it does merit further inspection and comment. For example, there may be specific instances in which join hints are necessary—you know you’re joining from a very small filtered subset to grab a tiny percentage of a bigger table (and you have an appropriate index on said bigger table), and so you slap on a LOOP join hint because the optimizer keeps trying to sort and merge join. But it’s worth explaining why and figuring out if there’s a better way, especially considering the consequences of slapping on that join hint.

Leave a Comment

Proper Disdain for ANSI-89 Join Format

Andy Brownsword has it together:

It’s a legacy pattern, and thankfully it’s rare to see these in the wild nowadays.

The legacy OUTER JOIN syntax (*= and =*) which used to accompany these was deprecated, and finally removed in *checks watch* SQL Server 2012, so that’s one less reason to see the aging syntax.

Every time I see this format, I despise it. Andy explains exactly why. We’ve had better options for more than 30 years, yet people still choose to write code this way.

Leave a Comment

Monitoring the Refresh of a Semantic Model

Reitse Eskens checks the logs:

As you’ve probably heard and read before, monitoring your Fabric environment as a whole is quite important. It really does help to know what’s going on.
Now, one thing I’ve learned over all these years is that report users do quite like their data to be as fresh and up to date as possible. And, when the data seems stale, they tend to ask questions.

Read on for some notes covering how to refresh a semantic model, when you might want to, how to automate it, and how to monitor the refresh process.

Leave a Comment

Tabular Editor CLI 0.6.0 Release

Ruben Van de Voorde announces a new update:

Since announcing the Tabular Editor CLI, we’ve been hard at work polishing the CLI and bashing the bugs we found, thanks to your help. We deeply appreciate all the input we received so far through GitHub, talking to you at events, comments on these blogs, and all other channels you engage with us (leave yours at the bottom of this page). Keep it coming!

We’re now at a point where we feel ready to share the updated version with you: version 0.6.0.

This is still in a limited public preview, so it’s free until the end of September. After that point, it becomes a paid product.

Leave a Comment

The Pain of Functions Wrapping Columns in a WHERE Clause

Rebecca Lewis answers a question:

This post is part of T-SQL Tuesday #200, hosted this month by Brent Ozar. The prompt: “When I’m looking at a query, I bet it’s bad if I see ____.”

Easy. I didn’t even have to think about it. When I open a stored procedure and see a function wrapped around a column in the WHERE clause, I groan. Out loud. Because more often than not, it means the predicate is non-SARGable, and non-SARGable means your indexes just became very expensive shelf decorations.

That is a pretty good answer, yes. Almost nothing good comes from wrapping columns with functions in the WHERE clause or as part of a join criterion.

Leave a Comment