Sunday, August 28, 2005

Are There Advanced SQL Editors?

Recently I've been on a tear about the quality of SQL editors out there. They all claim to be loaded with features that make our jobs easier and save time. The problem is that none of them really deliver... Ok, lets be honest, most of them are crap.

The problem as I see it is that SQL editors are being written by C++ programers and not SQL programmers. Of course, you wouldn't want a SQL programmer writing an editor unless he could actually do it in SQL, but you do want him scoping it out. Sometimes it's like they don't even ask the SQL guys what's important to them. They just figure that since they're developers too, that that have the same needs. This really couldn't be further from the truth.

Most of the editor features don't actually save you any significant time. Sure, they make the letters pretty and connect to code vaults like VSS, but what else do you have for me? Anything that will actually save me time? No likely.

There are so many SQL editors out there and they all have pretty much the same features, but they all have the same major flaw. They all treat DBAs and SQL developers the same. DBAs have completely different needs from developers and if you truly want to save me some time, then build an editor that I can use too.

So how do SQL developers and DBAs differ? Well, for starters, developers write long, complex processes that can be complicated and very difficult to troubleshoot. And though they may write large chunks of code that is very similar, it's quite often not the same, so templates are useful to them. With templates they can just replace the important data and keep the rest of the query in tact. These templates tend to be rather small, and completely void of logic. So, they would create a template for creating a certain type of function, or a blank cursor, but neither of them would have the actual queries they needed. Developers also need debuggers, but really not as often as you would think. I have developed some pretty decent SPs myself, and the number of times I've pulled out the debugger in 10yrs, I can count on one hand. That's mainly because most errors are fairly recognizable and a debugger really only needs to be invoked for logic errors that are difficult to chase down.

DBAs don't work like that though. We mainly do production type work which tends to be more troubleshooting, conflict resolution, and query/index tuning. We also do some connectivity testing. The code we write tends to be a lot shorter, often times just a single line, or several lines of independent code. Some examples of our code would be DBCC SHOWCONTIG() or sp_who2, etc. As you can see, every bit of the logic we need is right there. So DBAs tend to run the exact same code on every system they work on, not just code that's similar to other code.

That's really just one example of the differences in the way DBAs and developers work. I'm going to be putting together a list of features, and shopping it around to the different companies so we can get the editor we want built.
What I'd like you guys to do is email me the features you want with a brief explanation of why it's necessary, and I'll put it on the list. My plan is to not just submit the list to a company, but to take it to them and insist this is what their community wants, and not give them the list until they promise to build it for us. We want reasonable timelines too... not just a promise.

Let's get this done so we can finally get a real editor that will actually save us some time.

0 comments:

About Me

My Photo
Sean McCown
I am a Contributing Editor for InfoWorld Magazine, and a frequent contributor to SQLServerCentral.com as well as SSWUG.org. I live with my wife and 3 kids, and have practiced and taught Kenpo for 22yrs now.
View my complete profile

Labels

Blogumulus by Roy Tanck and Amanda Fazani

Page Views