Today I’m starting a new blog series called “SQL Server Infernals”.
Throughout this series, I will take your hand and walk you through the hell of SQL Server Worst Practices, as Virgil did with Dante in his Commedia.
You may ask why you should care about worst practices, when you have loads of great sources for Best Practices. The answer is that they are not enough.
- There are too many Best Practices: how are you supposed to know all of them?
- There is no time to follow them all: when you’re in a hurry, sometimes it’s enough to know that you’re not doing it completely wrong.
- They seem to be all equally important: experience helps you understand which Best Practices really are important and which ones are not.
- It’s not always clear what happens when you don’t follow them.
On the other hand, Worst Practices can help you understand what threat is behind the corner:
- They show you the mistakes to avoid
- You can learn from someone else’s mistakes (I made plenty throughout my career…)
Obviously, as usual, it depends: not everything is black or white and sometimes you will find in this blog series something that not everyone will agree is a Worst Practice. Sometimes you are forced by some constraint to adopt a solution that you will find here listed as a bad idea. No problem: nobody is pointing a finger at your work.
I will break the Worst Practices in categories, each one related to a specific area of SQL Server:
Stay tuned for your walk through the SQL Server hell!
Your pilgrim’s guide,
The SpaghettiDBA
