We can all recognise good-quality database code: It doesn’t break with every change in the server’s configuration, or on upgrade. It isn’t affected by concurrent usage, or high workload. In an extract from his forthcoming book, Alex explains just how to go about producing resilient TSQL code that works, and carries on working.
Did you ever wonder what the term “fill factor” in conjunction with SQL Server means and were eager to understand it better? The following two part article series explains what the fill factor is and how to choose the right fill factor for your database.
If you ever come to struggle with indexing your database objects the most efficient and profound way and suddenly realize you lack some background knowledge (like me), I just found a great four part article series on Database Journal by Gregory A. Larsen:

Interesting little trick to avoid table locks when updating a complete large table in SQL Server 2005 and higher.
Pretty T-SQL script returning a granular level of detail when looking at disk space usage of your databases. Shows disk usage of each table broken out by partition and filegroup. Could come in handy!
Execution plans can tell you how a query will be executed, or how a query was executed. They are, therefore, the DBA’s primary means of troubleshooting a poorly performing query.
There are dozens of things we can do in SQL that require some type of iteration. “Iteration” means “counters” and “loops” to most people and recursion to others. To those well familiar in the techniques of “Set-based” programming, it means a “Numbers” or “Tally” table, instead.