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”…)

15 thoughts on “How to Prove a Fact (Again)”

  1. I’m sending the link to the “Using NOLOCK as a first response to poor query optimization…IS BAD. ” to a certain … arguer.

    I definitely have seen the fact proving cycle happening way too often.

  2. Sadly, it doesn’t help that human nature takes the first thing that it hears/reads and treats that as more accurate than subsequent things, even if correct. (I think that’s what the first paper I read on this subject said, anyway.) That’s probably why “cursors == bad” seems to stick so hard to DBAs. Of course, so are multi-table cross joins because you forgot part of your JOIN syntax, but that’s another story. My favorite has been “table variables reside completely in memory”. That one is really well lodged in people’s minds for some reason.

    I like the part about credentials – brings back the memories of people arguing with Paul Randall over the way DBCC works or something similar. :)

    So what sort of credentials can I claim if I copied the article from the guy who wrote that piece of functionality and post it word for word on my blog to make a backup copy while simultaneously taking credit for writing BoL myself? That’s gotta be worth something. ;-)

  3. Peter,

    That counts as a half-cred :) If nothing else, you can always resort to DO YOU KNOW WHO I AM???? And then, leave em wondering and worrying…

    And it’s best to encourage people away from cursors. If one doesn’t know the proper use, one should stay the hell away. And my current campaign is against multilevel nested views…they seem so sensible from a coder’s standpoint, and they wreak so much havoc on the optimization engine…

  4. Proving a fact assumes you are dealing with someone that accepts that a thing called LOGIC should be the arbitrator of knowledge. Believe me, I have worked with people who have attacked me for reading books (I’m serious), quoting Gert Drapers’ **PERSONAL EMAIL TO ME REFERENCING THE TOPIC** (again, sadly, I’m serious), and would probably tell Paul Randall he was wrong about DBCC CHECKDB and BULK INSERT (both of which Paul produced, literally).

    You can’t reason with someone that rejects reason.

    1. Chuck,

      Agreed, but there are a few in the middle ground. For those who won’t listen, you’re forced to take whatever next steps you and your personal philosophy advocate. In Sean’s case, yelling and contacting managers and CEOs is well warranted.

  5. But what about multi-level nested views built on a really bad data model? Wouldn’t that make the badness cancel out?

    I agree about cursors, but they’re not always bad. Sometimes they fit a solution really well. I do find it funny when people look at a cursor and say things like “that’s bad, replace it with a WHILE loop instead to avoid using a cursor”.

    Chuck – thanks for the reminder. I can send e-mails to myself to prove my point by saying that I got an e-mail personally that explains this in great detail. I can understand being told that there are more important things than reading a book at a particular time, but not just for reading a book. :P

  6. Peter,
    Yes, the badness cancels out.

    Cursors, generally, are good when dealing with very few rows, as in administrative functions. But you start spreading that around and people gleefully use cursors to walk their dog, drive their car, groom their mustaches….

  7. Peter, this particular slice of insanity was attacking the act of GETTING INFORMATION FROM BOOKS, period.

    It was a particularly insane episode and was basically a contractor guarding his cushy gig and the client’s dependence on him (and him alone in perpetuity) – advances in technology beyond VBscript and SQL 2005 be damned.

    It reminded me of this:

  8. And they listened to you? You’re lucky. I was just talking about this on The Thread over at SSC. We have a guy where I work that is smarter than everyone. And I don’t just mean all us knuckleheads at the company. He’s smarter than all the MVPs. He’s smarter than the SQL CAT. He’s smarter than all the SQL Server developers. In other words, despite the fact that his code has been proven, in every possible way, to be wrong, reality doesn’t even leave a mark on this guy.

  9. Got it. Yeah, books are evil and contains all sorts of things that could be harmful. You just have to remember that this contractor was just looking out for best interests. :)

    Sad – very sad. Next thing you know you’ll be attacked for reading Paul’s blog or worse, something like BoL (I think I have those archived on a blog somewhere…..). I think it’s safe to say that we’ve all come across people like that who are threatened by more knowledge, and we’ve probably been that person at some point as well.

  10. Grant,

    Sounds like that guy has the “omniscient” cred claimed, but nothing else on my list. Shame…faith in a product is so much more fun when it’s backed by reality.

  11. “Closed eyes listen, afraid to see on their own. Easily influenced and simply conformed.” – Oscar Wilde

    More good quotes here: http://en.wikiquote.org/wiki/Wilde

    I rampage against cursors, even for single row operations. I have an analogy prepared, but so far unused: you have a cup of coffee and you want to put sugar in it. You can use a spoon, or tweezers. Cursors are tweezers.

    I’ve mentioned it to a few people but they were already against cursors, so I haven’t had to instruct anyone with it yet. But I am SO looking forward to making a developer actually do this, just so he/she can defend cursor usage. :)

  12. Rob, I like the spoon/tweezers analogy.

    I ran this accidentally great demo at SQL Saturday #52 Colorado. I’d slapped it together an hour before the presentation: it was a simple update of nearly every row in a table (725k rows) done via UPDATE, and same thing done row by row via cursor.

    The the UPDATE took 16 seconds.
    The cursor hadn’t finished by the time the class ended (1 hour 46 minutes and counting…)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>