Brent Ozar asks what makers us groan on reading in an SQL query, for this month’s T-SQL Tuesday.

Nowadays I look after 3rd-party databases more than internally-developed ones, so I accept there’s a whole lot of ex-best practices, vendor preferences, and possibly shortcuts in queries I might come across - whether it’s a poorly-performing query, a blocker, or an error.

(Although, when I developed software more frequently, I was guilty of all the gripes below. My start in SQL, last century, was poring over a big yellow “For Dummies” book. I was the dummy.)

SELECT *

In my experience, this is a shortcut that doesn’t save time in the long run. Often just the opposite - create a table, create a view with SELECT * FROM table1, update the table to add/remove columns, and the view breaks!
Instead: explicitly specify the column names. Yes, you may have to do it multiple times if you use common table expressions or subqueries.

Hungarian notation like tbl_Something, vw_SomethingElse

There was possibly a time where this helped, but I believe the art of writing software has moved on and Hungarian notation is no longer needed or desired.
My approach is: lower-case, snake-case table names that reflects the data stored, often in plurals e.g. users, addresses, categories etc. I don’t often use views, but once again I’d name based on data returned user_locations, addresses_no_deliveries etc.

Spaces in returned column names

I find this can cause problems consuming the query.
I favor: lower snake-case column names, I can always change the names in the viewer (R Markdown, Excel, Power BI etc.), and lower snake-case is what JSON uses.

Big long queries with no formatting or line breaks

Perhaps the return key was broken?
To fix: I format things how I want anyway, helps my readability. An LLM can do this easily.

Old school joins like …FROM table1, table2, table3 WHERE table1.x = table2.y…

I understand why people might write joins this way, but I’ve found that the join clauses may get missed or inadvertently commented out.
The modern alternative: is ...FROM table1 INNER JOIN table2 ON table1.x = table2.y..., which gives a natural flow to remembering the ON bits.

NTEXT and TIMESTAMP data types

These can appear in ooold databases and will cause headaches.
Strong recommendation: convert to modern data types to do anything with them.

Wrapping up

These are a couple of my query red flags. Of course there’s other things I don’t like seeing - index hints and user-defined types for every field come to mind - but I admit they may not harm the query or give me a headache when investigating.

I’ve been fan of Brent’s writing and work for some time (BlitzFirst is amazing, will hopefully have more to write on this), and I look forward to reading others’ takes on this month’s T-SQL Tuesday query nasties!