What the heck is ODBC? Pt 1

A couple of weeks ago, Kate, one of my colleagues, posted on our internal work platform the following puzzled request for help;

Kate works in a different time zone to me and, a little bit bored on the train home, I decided to think of how I would explain it.

I would say that ODBC as a principle/protocol is like the idea of the Rosetta Stone, in that it is designed to provide a mutually intelligible platform for databases which speak different kinds of SQL, and platforms which might want to talk to a SQL database, like Tableau or PowerBI. Despite our differences in language, we are all trying to communicate aspects of the human experience. However, different languages and cultures emphasise different things, which is one reason why different languages emerge.

ODBC is a set of protocols like the foreign dictionary section in a library. Most libraries will have common languages / standard drivers (French, Spanish, Chinese; SQL Server, Postgres, MySQL), but some languages you have to request, or are only used in certain contexts (Esperanto, Greek, Lithuanian; MySQL, Oracle SQL or Snowflake). All of these languages are very different, but they all communicate using the expression of certain sounds to correlate to concepts, as well as a structure of expression which allows us to mutually agree subject, object, and action. Importantly, they all have a form which is static as can be transmitted as glyphs on media such as paper or computing.

In the same way, ODBC protocols provide this mutual platform to bridge concepts; a bowl expressed in french or a bowl expressed in Greek refer to a household object, usually clay, to hold bitsy or liquid substances. Sometimes languages will have concepts which do not have corollaries in dictionaries: English and Russian have the word "serendipity", but Romance languages don't, in the same way some DBs can handle COUNTD and some can't. It depends on what the language, or database builder, prioritised at the time.

The question is, does the lack of word mean that the French cannot experience a spontaneous feeling of happiness, or a DB cannot count a distinct number of items (looking at you, legacy BigQuery) - or do we just work around it, knowing the words and functions that a driver can translate? For me, that is part of the art of development. Returning to the context of Kate's question though, we might image the following;

• Tableau: a patron of the library.
• Driver manager: librarian.
• ODBC driver: the dictionary.
• Relational database: the words, on the assumption that we are looking something up using written glyphs, perhaps in a common graphical system, like Latin, Russian or Chinese.
• DNS: the note to yourself that expresses the dictionary that you actually want. I will want a dictionary of NW European English, while Kate would probably want American English by default (but indeed, might need each others depending on the context). You will also have a trusted brand of dictionary (Merriam Webster over Collins, Oxford over Cambridge). For reference, the Scrabble dictionary in any language is fucking useless. Big SQL systems have standard drivers, but specialist items might have free and paid, for example.
  

Kate's example was within the context of a customer issue with Tableau, which generally is applied with relational databases, but she also asked about how we might think about this in the context of other kinds of databases (and what are those?). Alternatives to RDBMS: Graph databases, for one. How do you look up translations for signs in ASL?