I provide links to presentations (one with colleague Kevin Kline) at SQL Bits XII.
Category: Bad Habits & Best Practices
Last Thursday I presented my "Bad Habits to Kick" presentation at the New England SQL User Group; attached is the slide deck.
By way of an example, see why most of what you hear about SQL Server is only true some of the time, at best.
I see a lot of people suggest while loops instead of cursors in situations where row-based processing is required (or, at least, where folks think that row-based processing is required). Sometimes the justification is...
See why I prefer
alias = expression over the more standards-compliant
expression AS alias syntax.
See several examples supporting the idea that you should use catalog views, not INFORMATION_SCHEMA, in SQL Server.
Learn why you shouldn't use BETWEEN for date range queries, even with the date data type.
Read about some date/time shorthand you should avoid.
See why you should use sp_executesql instead of EXEC() for running dynamic SQL strings.
See an example that defies a generalization about performance of getting the largest value in a column.
In Boston today I presented my "Bad Habits to Kick" deck to 66 people. You can download the deck and samples from the SQLSaturday web site or directly from http://bit.ly/AB-71-Slides. Like the Chicago event,...
Your naming scheme isn't important, but being consistent is crucial.
In my last post in this series, I talked about problems associated with creating (and using) what I call the "uber-view." This time, in line with tomorrow's T-SQL Tuesday hosted by Mike Walsh, I...
In my last post in this series, I talked about using ancient copies of Books Online, and why it can be important to keep your local documentation current. This time I wanted to touch...
In my last post in this series, I talked about inconsistent table aliasing. Today I was reminded of another behavior that DBAs and developers alike can be lazy about: keeping Books Online current. There...
See why it pays to be consistent about always aliasing every table and every column in your query.
In my last post in this series, I talked about "blind SQL Server installs" and some of the potential consequences of making uninformed choices during setup (or of just accepting all of the defaults). ...
In my last post in this series, I talked about some problems associated with relying on undocumented behaviors and commands. This time I wanted to touch on SQL Server configuration, and some of the...
IDENTITY columns are very useful, but consider whether they are needed on every single table.
I tried to deploy nested stored procedures that both had a cursor with the same name. SQL Server didn't like it.
Find out about several bad things you may not even realize you're doing to dates and times in your own databases.