Today we have a guest editorial from Andy Warren at Steve is on vacation.
Imagine that you’re contemplating a project that will involve running multiple SQL statements and maybe some PowerShell against a list of instances, and then storing the results for later analysis. Based on that very short set of requirements, which tool would you think of using to solve the problem?
I’d say the options include:
- T-SQL
- PowerShell.
- VB.Net/C#
- SSIS
And maybe some I haven’t listed. Which one did you pick and why?
I’ll bet that your first thought was either the tool you know best or the one you want to learn/use. In my case I picked VB.Net because I wanted to refresh my skills and use some things I had not used before. But is that the right choice? How do you objectively decide which solution is best? Is it based on what you are best at, what is already in use, or what is best for the job even if it would take longer (due to lack of experience with it)?
I have a friend who argues that the most important consideration is how approachable the solution will be for the next DBA – the one that years from now will have to fix something that is suddenly failing. That DBA is going to appreciate the solution with the least amount of packaging – the noise he has to filter through to get down to the code. That’s not to say that every TSQL solution can be understood in an instant, but clearly it’s easier and quicker to get into a TSQL job step than it is to find and trace through compiled code.
I like the idea, yet it seems like I’m losing in one area to win in another. There is real value in trying out new/different technologies, both as a person and as an individual. Time to market might matter most, which in turn might mean using the tool you know even if it’s not the best or lightest.
Do you agree that packaging is the most important consideration? Or do you think that other factors matter more? Does your team/organization have a decision matrix to guide you? I’m looking forward to an interesting discussion in the forums!
