Calling all Editing Buffs...

I've been getting ready for a piece I'm doing on SQL editors and one thing rings clear in all the tools I've looked at. That one thing is that practically everyone who writes SQL editors either doesn't use them, or doesn't listen to their customers. There's really no such thing as a complete editor with all of the features that both DBAs and developers need. That's right, I said DBAs and developers because one major fact that escapes everyone is that DBAs and developers work in different ways, and therefore different things are important to each of them.

One of the things that is the most important (to us SQL Server folk anyway) is that any editor must give us everything Query Analyzer (QA) gives us and more. The problem so far is that nobody really gives us everything QA gives us. They pick and choose, and then fill in with whatever feature they like. That's not really a huge surprise though because I find that most DBAs don't even know how to use QA very well, so there's no reason I would expect a C++ developer to either. Anyway, the point is that since we're all mostly SQL Server DBAs or developers I'm going to be collecting a list of features from all of you guys (hopefully) and taking it to one of the bigger companies like Quest, Embarcadero, or BMC. I suppose though that one of the smaller guys could do it as well, and it's probably more likely to get our features into an actual product if we go to a smaller company. The plan is to give them the features only if they promise to build the product we want. No ‘we'll look into it' or ‘we'll see what we can do'. I'm only turning over the list if they promise to give us our features in a fairly reasonable timeframe.

Let's take a quick look at the differences in how DBAs and developers work so we can understand the need for the different tool sets. And again, this was mainly brought about because most editors all but completely ignore the needs of the DBA.

Developers- Writing and debugging relatively large scripts. The need for code management and versioning is very important. Code templates are more important than reusable code because different projects quite often will require the same types of objects, but not the exact same objects.

DBAs- Writing relatively short scripts to be used over and over. The need for code management and versioning isn't very important. Templates aren't as useful as reusable code that is easy and fast to get to. Pretty much anything a DBA will do to diagnose a server will be done on any server he diagnoses, so the reusable code is the key here. Also, the repetitive nature of production DBA work lends itself to different features than development.

However, there may be some exceptions, and maybe some finer nuances, this is the overall nature of each of these positions, and this is the supposition we'll be using to design our editor.

Code Reuse:

One of the most important features is a centralized code repository. This can be used by both DBAs and developers, but DBAs are really the ones who'll use it the most. Developers can easily check code in and out of a code vault like VSS, but DBAs usually don't even have access to a code vault, and really don't have time to go through the procedure to begin with. Remember, DBAs need things in a hurry. So, DBAs need 2 things… a code repository, and auto-replace. The specific features of the repository can be hashed out in future articles because I have a lot of ideas on this, but for now let's just say that a repository for all of your troubleshooting code will get the job done.

One of the biggest arguments for the repository is standardized troubleshooting. The team can get together and decide on the best code to use to troubleshoot their servers, and put it in the repository. Then when problems occur, they all pull from the same code, so everyone knows exactly what can and can't be done, and what load it'll put on the server. It really shouldn't be such a fresh idea that DBAs synchronize their code like developers do, but hardly anyone does it. They rely on the knowledge of the specific DBA to write his own stuff, or pull from newsgroups and alter the code himself.

There's much more I can discuss about the different features, but for now I'll just list a couple of them and I'd like you guys to submit anything you have in mind. Of course, the more descriptive you can make it the better you'll be understood, and it's always best to give a business reason so we'll know where it's applicable.

I'm only going to list two here because if I give the entire list, there won't be any reason for any of the companies to work with us. My list has about 20 items so far I guess.

send me your suggestions in more or less the same format. I'm at KO@KenpoSecrets.com