At the Feet of the DB Guru

The weary traveler is not just tired because of the difficult climb.  A solid two weeks of frenzied late night debugging had him running on no almost sleep and at some point even Red Bull's wings turn into nothing more than comfy sheets on a soft bed.

This was the last straw.  No, this was the last gasp.  He had tried everything.  It had all failed.  The numbers were not tying out.  Every valuation had to be double-checked and manually corrected and as the weeks wore on it was getting worse.  

On the Trail of a Myth

The DB Guru had long been a hacker legend.  Some doubted he still existed.  Some called him a myth.  The Guru knew all.  The Guru could fix it.  He was said to have downright clairvoyant debugging abilities.  The Guru would help.  The Guru had to help.  Our weary traveler was out of ideas.  After all, he had followed the debugging checklist:

• Have you tried rebooting the server?  Fingers crossed .... didn't work!
• Is your DB server patched and up-to-date?  Check.
• Are you running the latest version of the DB driver?  Roger that.
• Have you tried blaming Tibor?  Boss not buying it ... this time ...

The DB Guru

The DB Guru lived at the summit of Mount OnesAndZeroes.  Legend holds that the advent of code generators and ORMs had caused him to withdraw from active database development.  At one point the DB Guru was the most sought-after database resource in the field.  But as client-server migrated to multi-tiered, command line had given way to GUIs, Notepad had given way to development suites and "knowing the commands" had given way to code-completion the criticisms had begun to swirl around him:

• Too old school.
• Too set in his ways.
• Resistant to change.
• The technology had moved beyond him.  

Legend has it that the DB Guru had seen the writing on the wall.  He had stepped aside, removing himself from the community.  Cloistered in his summit hideaway, he was free to pursue his art.  He rarely received visitors but to those willing to seek him out - the desperate and the humble - he was said to offer sage advice.  

After listening to the pilgrim's tale of woe the DB Guru sighed.  He set aside his Lappy 486.  His eyes took on a faraway look and he began to speak with a cadence that indicated this was not the first time he had relayed this wisdom.   Grabbing two discarded pizza boxes (from a sizable stack atop Mount OnesAndZeroes), the pilgrim had two tablets onto which the following advice was recorded.  This is what the Guru said.

At the Feet of the DB Guru

1. Normalize till it hurts - denormalize till it works.
2. Relational databases are not necessarily the answer.
3. Consistency is good, but a foolish consistency is the hobgoblin of little minds.
4. Query optimizers and query hints ... humph ... a database developer craves not these things.
5. Speed starts with RAID configuration, then filegroups, then partitioning, then clustered indexes and finally indexing directed at structural weakness.
6. In SQL Server the preferred floating point format is decimal.  Others offer the illusion that precision and specificity are the same thing.
7. Fast databases recognize the word-size preference of the database engine. and do not confuse that with mere datatypes.
8. The presence of referential integrity is not necessarily indication of a well-thought-out database.
9. Empty strings == nulls.
10. What will it gain you to declare a set of columns a "primary key" over a "clustered unique index"?

Inspiration and Acknowledgement

With a nod to my own DB Gurus:  Dale Vickers, Ron Mahlmann, Charles Waugh, Shannon Sheppard, Jeff O'Block, Alex Glauberzon, Ron Sutherland, Doug Campbell and a host of others.