Welcome to my first post on the new sqlHammer blog site.
My name is Derik Hammer and I’m a believer in sharing knowledge. Few people understand how powerful the old saying, “Feed a man a fish, he’ll eat for a day. Teach a man to fish and he’ll eat for life,” really is. Even if you teach someone something that you will never meet or even know that they learned from you, it is still powerful. I have noticed countless occasions when I’ve taught something to a person and days, weeks, or even months later that karma came back and rewarded me for it.
In the interests of spreading knowledge I have started to blog about my experiences and hope that others can benefit from stories about my mistakes. If you’d like to know a little more about me you can navigate to the ‘About Me’ section of my site but for now I wanted to open this blog with a short story that motivated me to begin using PowerShell as a primary tool when administering my database servers and that shares a name similar to this site and my name.
The T-SQL Hammer
Some of you who often read these types of blogs and articles, like I do, will probably recognize this heading. That is because it is the title of a blog post by Chad Miller which I first found while reading a post by Laerte Junior titled I’m a SQL Server DBA, and I’m in Love with PowerShell.
The concept of the T-SQL Hammer is, “if all you have is hammer, everything looks like a nail.”
We all use T-SQL in almost every corner of our occupation. In fact, the more I wrote scripts to do what I need the more cumbersome GUIs and some of the other SQL Tools feel. This was driving me into a situation where I became more and more tunnel visioned on T-SQL as my only tool.
That’s when I was lucky enough to come across Chad and Laerte’s posts and I woke up. That same day I began trying to use PowerShell a little bit everyday and since I too have come to love PowerShell. In addition to learning PowerShell I’ve been doing a lot more researching on service based architectures, understanding that the database layer doesn’t have to do all of the work when moving data around, and I’ve become more open to non-SQL message queuing technologies such as Biztalk (even though it is extremely expensive), MSMQ, etc.