Standards Are Frameworks, Not Instructions
Every so often, somebody asks me: "Why is it so much work to add support for Database X? They support SQL and ODBC!"My response usually takes about 20 minutes. The first 18 minutes are comprised solely of me standing with my feet shoulder-width apart, back slightly bowed, arms raised and fists clenched, face turned skyward, screaming a single unbroken roar of sheer frustration and unbridled hatred. I then spend the last two minutes explaining the following answer: standards are frameworks for communication, not instructions for execution.
SQL and ODBC (and JDBC, etc. etc. etc.) define ways for two systems to communicate with each other. They do NOT define how either party in the conversation should actually behave. Thus, a system that understands SQL or ODBC is not necessarily going to behave the way you want it to. Heck, it might not even understand what you're asking of it.
To re-use an old example, consider the case sensitivity problems I've described in previous posts. SQL Server understands SQL and ODBC, but as those examples show, it isn't necessarily going to execute your query the way you want it to. And that problem can arise just between two different installs of the same RDBMS - imagine the problems trying to move to an entirely different system!
Let me close with a fun little analogy:
ODBC is to SQL as ears are to English
All humans (or almost all, anyway) have ears. Americans and Australians both "speak English". But would you expect an American to be able to communicate perfectly with an Australian? They might be able to figure things out, but it wouldn't happen perfectly the first time. They both share common frameworks for communication, but not all the words mean the same thing.
Trackbacks
Trackback specific URI for this entry
Comments
Add Comment