Category Archives: Miscellaneous

Hodge-Podge of things that tickle the Blimp’s fancy.

SQL Terms of Art — Pronouncing them correctly

There is English.  There is also geek-speak.  Then there is DBA-Speak.  Then, for the truly advanced among us, there is SQL Server DBA-speak.

However, if we are to sound like professional DBAs and not newbies, we must pronounce our terms of art correctly.  Failure to do so can result in: (a) Losing the chance to speak at SQL Pass Summit; (b) Being uninvited from the cool vendor parties at the Summit; (c) Generally being ostracized by the SQL DBA community; and (d) Death.

So, here are some terms that are often mispronounced, along with the canonical ways to pronounce them:

SQL:  Spell the letters, lose your job.  It is pronounced SEQUEL.

SQL Versions:  Never insert the word “server!”  It’s “SEQUEL TWENTY FOURTEEN” and not “S Q L Server Two Thousand Fourteen.”

The Data Type CHAR:  Is it pronounced CHARR, like the delicious blackened coating on a delicious piece of steak served at a vendor party at SQL Pass Summit? Or is it pronounced CARE, like the first symbol of “character?”  The latter pronunciation is a capital offense.

The Data Type VARCHAR:  This is more complex, because we have multiple pronunciations:

  • V-ARE CHARR:  the Rhyme-like pronunciation that shows that you are a mighty DBA and not some poseur.
  • V-AIR CHARR: Welcome to poseur world.
  • V-ARE CARE: Capital Offense
  • V-AIR CARE: Double Capital offense.  They execute you, wake you up, and do it again.  Sort of like the end of Braveheart.

SARGABLE:  Short for “search argument able.”  This refers to the good situation where a WHERE, HAVING or ON clause doesn’t do silly things like wrap the searching column in a function to force a scan.  It lets SQL use indexes.  Is the word pronounced SARGE-able, sounding like a short name for a Marine Drill Instructor?  Or is it S-ARGH-able, with the hard G?  Finally, could it be S-AAAAARGH-able, as if the DBA is a pirate?

In this case, the first or the third are equally cool.  However, a DBA may only use the third version at SQL Pass Summit, and only when presenting, and only with a parrot perched on his or her shoulder. Use the second version only if your résumé (and you must type the word with the accented “e” in both places) is up to date.

Standardization is important.  This standard will be updated as new terms of art arise.  Feel free to contribute your own goodies.

Happy New Year!

I wish you all the happiest 2015.

May your queries never be accidentally Cartesian.

May your DBCC CHECKDB always come back without inconsistencies or errors.

May none of your databases ever be marked suspect.

May both your budget and your salary increase.

May the next packaged product that your company installs come with a database that is properly normalized, with the correct indexes, and following all best practices.

May your monitoring tools never generate false positives.

May your new SAN contain nothing but solid state drives.

Have a wonderful new year!

Why I chose WordPress and how it relates to modern DBA work.

This is a new blog.  I decided that I could go home-brew and spend a while creating and debugging something, or I could get busy and put up a new site (using Azure Marketplace – Microsoft please send check to me  in a day).  I chose the latter.

WordPress makes a complete and easy to use blogging product.  It was simple to get it up and running.  Much better than reinventing the wheel.

I’m an old geezer in the IT world, starting work over 30 years ago. As such, there is a strong desire within me to craft every solution from a blank slate.  However, times change.  Adapting to those changing times is important.  Is my winter vacation time better spent developing something already well-done by others, or with family? This choice is a no-brainer.

We see this all the time in the work world.  Companies have wised up.  What company builds an ERP solution from scratch anymore? A package is purchased, customized features are added, and the product is deployed.  For DBA this is a challenge set all its own.

Packaged software vendors rarely prioritize the needs of a SQL Server DBA to maintain performance as an application scales.  For many packaged products, things like Entity Framework and SQL generators restrict DBA query tuning options.  Database structures are mostly out of DBA hands, meaning that the options for fixing poorly-envisioned table structures and the like are also limited.  How do we respond when performance tanks?  Is the performance-tuning role of a 21st-Century DBA relegated to tossing indexes over the fence? May it never be!

As the site grows, I will share more and more about how to deal with these frustrations and challenges.  I also look forward to your comments.