Chapter 1, or Seeking Truth in Database Theory

Upon first receiving the SQL Server MVP Deep Dives book, I immediately sat down and entrenched myself in the first essay – a summary of 10 key relational database design ideas, by Paul Nielsen and Louis Davidson.

I instantly developed a man-crush on this essay.

It said many of the things I had always wished were in print together, and like many of you out there, I secretly wished this list was something all development DBAs had to sign off on before they were even interviewed.

Because of this, I could easily jump into a story and tell you about how I make junior DBAs recite these 10 commandments every morning, much like a pledge of allegiance to the great and powerful nation of Data.  Or, I could speak to what rules I’d like to add – if 10 wasn’t such a perfectly round number – such as the lesser axiom “Don’t even think of applying for a SQL 2008 job at my company if you’ve never heard of a CTE”.

All in all, though, I think if you’re reading this blog, then you’re probably already in agreement and also have a few dozen rules of your own (feel free to leave them in the comments!).

Let’s look at the first day of work for Rick the DBA.  Feeling deliriously satisfied with his luck at having a job in this economy, he heads in to the office and meets the rest of the staff.  First, he meets John the Developer.

See John.  See John code.  See John code .NET.  See John code .NET and store all his objects as untyped XML blobs in a big table called [IHateDBAs].

Next Rick meets Emily the Project Manager.  Emily is nice and sweet – until she speaks.

“I know you’re new here but the application John has been working on is working slower and slower and he said we could add something called an index to fix it but after a few weeks of working on it he told us we needed a DBA and so here you are!  Anyways what do you think, how’s the end of today sound for getting that index thing installed?  John said it would be easy for someone with your skillset”.

Rick goes home that night and softly cries himself to sleep while clutching his well-worn copy of SQL Server MVP Deep Dives.

As a technical leader, the question that perplexes me is, how do I create a corporate culture that accepts there are reasons behind these rules, and that they aren’t merely the reflection of a couple of crazy people trying to push their crazy little mindsets on the rest of the crazy world around them?

Let’s say I see a global cursor declaration and notice that the purpose of this cursor is to summate all the currency values in a column.  Now, I was first trained in leadership in the United States Army, and therefore my first impulse is to move precisely three-quarters of an inch away from the responsible person’s nose and have a pleasant conversation at 120 decibels on the popular topic of pond scum and how best to wipe it off a bayonet.

Sadly, that’s frowned upon in our politically-correct modern business environment.

Truthfully, the responsible person probably isn’t even a DBA.  They are more likely a VB developer who does database work because the company never hired a DBA, or perhaps they even have a DBA title but were not ever trained for it and were hired by someone with even less of a clue.

The first theorem that needs to be established in any company involved in database development and maintenance is thus:

Database Development and Maintenance is a distinct discipline of its own.

You wouldn’t ask a developer to rebuild the company’s Active Directory infrastructure, and you wouldn’t ask them to piece together a SAN from leftover wires and 555 timer circuits in the unlit broom closet.  You have Infrastructure people for that.  So, why ask a developer to make a stored procedure, or design a table structure?  Are you really surprised when it doesn’t work out well?  Let’s expand this concept in our first corollary:

Only qualified candidates should be considered for Database positions.

Given the choice between “Ben” the Java developer and “Lisa” the certified database developer, who’s better for the job of developing database code?  Now ask yourself, how many times have you seen a “Ben” making databases somewhere?

More difficult:  what if you wanted to hire someone to write a bunch of report queries for a financial audit – do you choose a database candidate that has spent his entire adult life working out complicated backup strategies and SAN allocations, or do you choose a database candidate that spent the last 2 years writing stored procedures for an ERP?  This leads us to our next corollary:

Even within our distinct discipline, there are specialties.

If you have a hiring manager or HR recruiter that cannot comprehend this, then they shouldn’t be in the decision loop.  How many times have you had a resume with SQL acronyms splattered all over it, yet it still lacked even the most basic skill you were looking for?  Oracle versus SQL Server.  Administration versus Development.  These broad categories parallel examples in other technical disciplines:  Java versus .NET; Windows versus Linux; Server design versus Network design.

As a technical leader, you must sell this concept to your peers and to senior executives.

Our last corollary comes from the simple fact that we rarely have the luxury of being in a completely technical company.  You must seek out specific examples of how the profitability of your company is being damaged from improper separation of technical disciplines.  This is usually easy, and comes in the form of confused clients, failed audits, or elongated call times.  What call center wouldn’t want to chop 45 seconds off of every 10 minute call?  That is a lot of ROI.  You have a fiduciary responsibility, if you are in a senior leadership role, to reveal these risks and encourage corrective action.

Technology is still young as a field, and sometimes it grows faster than our understanding of its nuances.  This should not discourage us from seeking greater truths and encouraging those around us to do the same.

Dale Lamb is a proud veteran of the US Army and several US Corporations, from startups to Fortune 20.  He is currently packing his bags for an expat tour of duty in Australia where he will be a Managing Database Architect in the medical software industry.  If you go there, perhaps you will see him on the white sand beaches, reciting sacred database commandments to the locals.