Discover some undocumented or unsupported behavior you might not even realize you're relying on.
Category: Bad Habits & Best Practices
An index of over a decade's worth of posts and videos involving bad habits and best practices in SQL Server.
Originally published in 2009, I updated this in 2019 with an example showing an effect on the plan cache.
Aaron Bertrand explains four conventions he always follows when writing T-SQL queries.
Get a first-hand look at some of the ways NOLOCK can produce incorrect data.
By way of an example, see why most of what you hear about SQL Server is only true some of the time, at best.
Learn why you shouldn't use BETWEEN for date range queries, even with the date data type.
See an example that defies a generalization about performance of getting the largest value in a column.
See why it pays to be consistent about always aliasing every table and every column in your query.
IDENTITY columns are very useful, but consider whether they are needed on every single table.
See why you should avoid some of the GUI elements in Management Studio.
Let's talk about a few of the ways people abuse and misuse DML triggers in SQL Server.
Read about some of the pitfalls of choosing the wrong data type in SQL Server.
In my last post in this series, I talked about using the schema prefix, with particular focus on dbo-only systems. In this post, I want to treat the use of inconsistent naming conventions. Stored...
In my last post in this series, I talked about inappropriately using SELECT, OUTPUT and RETURN in stored procedures. Today I wanted to talk about using SELECT * or omitting the column list entirely....
See why your stored procedures should use OUTPUT and SELECT for data, and use RETURN only for error or status codes.
In my last post in this series, I talked about defining varchar columns, parameters, or variables without length. Next I want to talk about using "bad" characters, like spaces or dashes, in entity names....
Find out why you should always specify lengths for declarations of variable types like varchar.
A little wisdom on using sensible and logical aliases for your tables, instead of a / b / c / d.
See a couple of reasons you should stop using old join syntax (
FROM t1, t2).
See a few alternatives to expensive loops for populating sample or sequential data.