T-SQL & Development

Get Your Blog Posts Ready for T-SQL Tuesday #200. Here’s the Topic.

By Brent Ozar · June 23, 2026 · 53 comments

Way back in December of 2009, Adam Machanic published a blog post (archive) in which he invited database bloggers to participate in a new monthly event he called T-SQL Tuesday. Each month, he (or a blogger he picked) proposed a topic, and on that date, we’d all publish our blog posts at the same time. It was a fun way to get a variety of opinions about a topic.

T-SQL Tuesday has been going strong for over a decade, but a lot has changed. Adam’s original blog site is gone, there’s a new archive of the monthly posts, and Steve Jones has taken over coordinating the event. If you’ve got a spare afternoon, going through the archives is a fun way to learn a lot about topics – everything from Extended Events, date/time handling, windowing functions, encryption, and more.

A whole lot less gray hair
Me in 2009

Our industry has changed a lot in that time span, too.

But you know what hasn’t changed?

There are still a ton of readers out there who need help with T-SQL.

And that’s where you come in, dear reader. If you’ve got a blog, even if you haven’t written a post since the pandemic, even if you’ve moved on to other technologies, if you’re reading this post, you’ve got something to offer the countless readers who are just getting started on their database journeys today.

Here’s your topic:

“When I’m looking at a query, I bet it’s bad if I see ____.”

I bet just reading that sentence, you had a knee-jerk reaction or three. You think about opening up a report query, a stored procedure, a function, trigger, or EF code, and when you see that one thing, you go, “Oh no, this was probably written by That One Person™, and they were probably using AI, and I’m gonna dread reading the rest of this and I’m gonna have to fix it myself because the whole query is probably a hot mess.”

Take that knee-jerk reaction, go over to your blog, log in, and write a few paragraphs about why you don’t like seeing _____ in production code, the problem that it’s caused you in the past, and what you recommend instead. Don’t second guess yourself, and don’t think, “Well, somebody else is surely going to write about ____, because everybody knows that’s bad.” First off, they don’t! You would not believe the misguided queries I see at work every day. Second, if a bunch of bloggers chime in with the exact same hot button feeling, that’s GREAT, because it illustrates to the audience how bad that particular thing is.

Don’t be intimidated. Your target audience isn’t me, Kendra Little, and Erik Darling. Your target audience is 2004 Brent, the guy who had never been to a formal SQL Server training class in his life, and who, when he needed to write a new query, opened up some other query written by someone else earlier, copy/pasted it, and started from there without really understanding what he was inheriting. Trust me, no matter what you’re warning 2004 Brent about, he’s going to be surprised, embarrassed because it’s in his own code today, and he’s gonna read your post carefully to take copious notes.

Schedule your post to go live on July 7th or 14th, include #tsql2sday in the title, and include the image at right. Include a link back to this blog post, or come back here and leave a comment linking to your blog post. One week later, I’ll publish a roundup blog post linking to everyone’s opinions.

Thank you in advance for continuing to dedicate your time to improving everybody else’s experience in getting started on their database journeys. It’s people like you that have helped us all move our skills forward over the last 100 months, and will continue to keep moving things forward over the years to come.

 

Free, 3× a week

Get my new posts by email

Three posts a week, plus a Monday roundup of the best database news from around the web.

Keep digging

Never, Ever, Ever Start T-SQL Comments with Two Dashes If Your Trigger Uses UPDATE(), It’s Probably Broken. Should we use stored procedures or queries built in the app?

53 comments

  2. Correlated subqueries. Usually multiple ones across the same table, all of which could have been resolved by a join.

    Reply

    1. Scott – I’mma be honest, my first reaction was, “That’s ridiculous,” but then I realized I must have been finishing mine with semicolons for a decade now, and NOT doing it would indeed seem really weird. So I agree!

      Reply

      1. The missing semicolons are just the indicator of stranger things to come. I know I’m going to find all sorts of interesting ways the developer deviated from the norm and went against common standards.

        Reply

        1. You’re absolutely right—missing semicolons are just the tip of the iceberg. It’s always fascinating to see how far someone strays from the norm when they skip the basics.

          Reply

    1. Hahaha, Brent04 – man, I’m surprised by how often I find that repeated-update-pass problem! People just keep copy/pasting the same update statement and tweaking it to handle different situations in the business data, and next thing you know, you have a night-long ETL process. Thanks sir!

      Reply

    1. Got it! Yeah, the wrap-up won’t hit until next Tuesday – a couple of old-school folks asked me to wait so they could publish their entry on the 14th, heh.

      Reply

    1. JEFF. Buddy. Pal. You slink in here late, and your homework for “I know a query’s gonna be slow when I see … too many indexes”

      JEFF

      JEFF, I’m gonna need you stay after class. 😉

      Reply

Leave a comment

Your email address will not be published. Required fields are marked *

Email me about new comments: