For the bicentennial edition of T-SQL Tuesday, Brent has thrown down the topic of “When I’m looking at a query, I bet it’s bad if I see ____.”. I’m expecting the Brits out in force for this game of Blankety Blank.
There are some things which terrify me when troubleshooting:
- The comment ‘it’s always been this way, don’t touch it’
- Join hints scattered like Salt Bae was the original dev
- My name on the last commit 😬
Not necessarily in that order.
But there’s one indicator which immediately highlights aged code for me:
It tickles me the wrong way…
SELECT ...
FROM Sales s,
Customer c,
Product p
WHERE s.CustomerID = c.CustomerID
AND s.ProductID = p.ProductID
AND c.IsActive = 1
AND p.Category = 'Books'
AND s.OrderDate >= '2026-01-01'
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.
But here’s the real issue: distinguishing between join and filtering predicates. Throw in half a dozen tables, with aliases, and additional filters, and you’ve got a wall of text greeting you when it’s time to troubleshoot. Readability is crucial.
There’s no performance impact to using this syntax. But if the readability trips you up and you miss the join condition, you could fall foul of a cartesian join.
We know this looks much cleaner than the example above:
SELECT ...
FROM Sales s
INNER JOIN Customer c ON s.CustomerID = c.CustomerID
INNER JOIN Product p ON s.ProductID = p.ProductID
WHERE c.IsActive = 1
AND p.Category = 'Books'
AND s.OrderDate >= '2026-01-01'
So if you happen to be one of those last remaining devs, here’s why we use ‘modern’ join syntax:
- Joins and filters are clearly separated
- Join types are clearly distinguished between
INNER,LEFT,RIGHT - Harder to miss a join predicate and end up with a cartesian join
- Your complex queries will finally be readable
Comma joins aren’t dead yet, and they aren’t making your query slower. But they’re a strong indicator that you’re looking at some legacy code. When I see them, I’m prepared for an interesting afternoon.
With that out of the way, I wanted to recognise this milestone edition of T-SQL Tuesday.
I wanted to close by giving thanks to Adam’s creation and Steve’s continuation of the enduring T-SQL Tuesday, along with a vast array of hosts throughout the years.
I feel like something of a newcomer with my earliest submission back at #128 about learning from others, which is apt given how much the community shares through these monthly topics. I’ve enjoyed the variety of off-topic subjects and more so in reading from responses across the community each and every month.
Thank you to everyone for your past and future contributions. Unfortunately I don’t think we’ve got the budget for UFC title fights. Or fireworks. So 🎉
Andy Brownsword 