Whenever I sit down to write these editorials, I always intend to pass on some small but useful nugget of technical wisdom. I want to try to communicate, as simply as I can, some piece of knowledge or understanding that will help others do their jobs better. I'm a tranquil sort of guy, interested in harmony, peace and goodwill to developers and DBAs alike, and I love to share my technical insights.

The problems start when I feel that strange compulsion to "pick on" a dubious database practice and attempt to subtly or not-so-subtlety point out why it's dangerous and wrong. Suddenly the red mist descends and I find myself, for example, using Napoleon's defeat at Waterloo to explain why maybe, just maybe, you should STOP USING NOLOCK ON EVERY QUERY…! My audience pales as my jowls quiver with indignation.

In short, I feel more and more like this approach can end up being negative. Without care, the editorial descends into hectoring the audience. Do your homework! Eat your vegetables! It reads like a list of commandments suggesting that you're all doing it wrong. Despite appearances, the inner Grant doesn't really believe this. In fact, I think, most people, most of the time, make great and interesting choices in designing, building and managing their data systems. You're unsung heroes who keep the lights on in a million ways that no one knows about. Do you always follow all the prescribed best practices to make this happen? Not just "No", but "Hell No".

You know what? That's OK. Success as a DBA is not predicated on listening to the right person tell you the right and wrong ways to perform a given database task. It's about learning, through hard work, many different ways to perform a task, so that you can find a solution that will work for the business regardless of the shortcomings or peculiarities that confront you, in the application or in the system architecture.

<Cue 'sincerity' music on distant strings>

So today, no advice. No suggestions. No historical or fictional references that try to tie together with a point about data, data management, IT processes or leadership. This is the un-editorial, the anti-editorial, the editorial free from editorializing.

Instead, I'm going to say thank you. Thanks for helping us get the software out the door even though we had a couple really bad column names. Thanks for getting an index in place that keeps the database functioning despite that questionable database design. Thanks for figuring out how to get my data back even though we didn't have a good backup scheme in place. In short, thanks for all you do. You rock. We, all of us who are dependent on you and what you do, appreciate it.

Just steer clear of multi-statement table valued functions, and everything will be OK. Huh?

Grant Fritchey.