In a comment to my previous post, Rich asked
Does this mean you’re the person to fix T-SQL programmability?
I honestly don’t know the answer to that question because, coming from the outside, I’m not sure about everything that’s wrong with T-SQL. I’d love to hear more from anyone who’s got an opinion (and any pointers to complaints around the web would be welcome as well). You can also feel free to use my contact form to talk to me directly. I can’t promise I can do anything at this point, but I’m looking to learn.
What I can do is offer two thoughts about why I chose to move over to the T-SQL team:
- Even though I’ve been interfacing with SQL Server for nearly 20 years in one capacity or another, I only know a surface amount about it-basically, some standard SQL and that’s about it. A lot of the reason for that is because T-SQL always seemed, well, a little arcane from the outside. I sort of got the basics of querying, but beyond that I never felt I really had the time to figure things because they looked. complicated. Some of that, I’m sure, is just the usual “people look strange when you’re a stranger,” but I have always wondered what might be done to make SQL Server and T-SQL a little more approachable.
- Along those lines, one recurring situation that I’ve found with SQL Server (both personally and observing others) is that the perceived impenetrability of T-SQL causes people to waste the wonderful opportunity to leverage the power of the server and instead use up precious time sucking data down to the client just to do a bit of processing that could easily have been done as a part of the query. The question comes to mind: what could we do to enable people to more easily capitalize on the server resources that are available to them, and how can T-SQL play a part in that?
So that’s what my hopes are, we’ll just have to see how it plays out.