Blog Post

How to Prove a Fact (Again)

,

Sean’s latest rant – about a vendor with a dangerously small amount of SQL knowledge – has spurred me to talk about a common theme I’ve been seeing lately: Proving facts to ignoramuses*.

How to Prove Facts to the Unbeliever

  1. State the fact.
  2. Explain the fact.
  3. Restate the fact. [Realize here that they won't listen to a thing you say, even if you show them.]

  4. Go find indisputable industry experts (product documentation from the owning company, testimonials and blogs from members of the development team, and/or clearly documented tests with results).
  5. Email it to the unbeliever, copying his boss and everyone who was in earshot of the original dispute.
  6. In the email, prominently mention your credentials to really put the slam on the infidel  (10 years in the industry, certifications, MVP, articles and books you’ve written on that subject, the fact that you wrote THAT PARTICULAR PIECE of the SQL engine, status as owner of Microsoft itself, omniscience, etc. as appropriate).
  7. Perform the victory dance of your choice.

Note on step #6: Establishing your credibility never works as an opening gambit. You could be the internationally recognized reincarnation of the Buddha of database administration (whoever that might be), and some jackass will still say “Yes, but you just don’t UNDERSTAND high availability like I do…”

Proofs to Recent,  uh, Arguers

Backup operations DO NOT CAUSE BLOCKING. Citation: Paul Randal, A SQL Server DBA myth a day: (30/30) backup myths

Using NOLOCK as a first response to poor query optimization…IS BAD. Citation: SQL Server Books Online, Table Hints

Cursors ARE WAY WAY WAY SLOWER THAN SQL STATEMENTS. Avoid them. Citation: SQL Team, Cursors: An Overview

Happy days,

Jen McCown

http://www.MidnightDBA.com/Jen

* (Crapola, I wonder if there’s a proper spelling of “ignoramuses”…)

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating