What's In Your SQL Server Library?

2016-09-29 0 Comments

Team Foundation Server - DefaultCollection

When you're faced with a new task or some other SQL Server challenge you've not tackled before, what's your go-to strategy: Author your own solution? Or use someone else's? There's no right or wrong answer. Each option comes with its own pluses and minuses. The more interesting question is this: If you had to craft your own solution, could you?

I came across a quote about software development many years ago. It's killing me that I can't find it now, but it went something like this:

"It's great to reap the benefits of another's library, but it's even better to amass your own."
That's "library" in the software/code sense, not the librarian/Dewey Decimal sense (if you're old enough to know what that is). I doubt the author had SQL DBAs in mind with that sentiment, but I still think it applies to us. I don't propose "reinventing the wheel" as a default strategy. But there's a case to be made for coding your own solutions from time to time.

Last week, I saw a great example of a DBA with the "do it yourself" spirit. Take a look at this tweet from Michael Swart that I replied to:

Within an hour, Michael had created a working event notification for the DEADLOCK_GRAPH event. To be fair, Michael is a Microsoft MVP. And it looks like he has a lot of experience to draw on. Nonetheless, that's pretty impressive for a guy that had never heard of event notifications. Heck, he even blogged about it a mere two days later.

What's in your SQL Server library? Are your fingerprints in there anywhere? I encourage you to contribute to your own library every now and then. It will make you a better DBA.