Situation Analysis
It’s the year 2019, and the fundamental issues associated with data access drivers utility remain confusing. Basically, we remain uncertain about the value-to-compensation alignment of Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), and ADO.NET drivers/providers.
ODBC Architecture for DBMS Independence
JDBC Architecture for DBMS Independence
Why do we pay for anything?
After allowing for consumer irrationality, the basis of any payment is fundamentally tied to the monetization of opportunity costs. Essentially, we pay for one thing to alleviate the (usually higher) costs of something else.
The rest of this post focuses on highlighting the real pains associated with the $0.00 value misconception associated with Data Access Drivers: ODBC, JDBC, ADO.NET, OLE-DB, etc.
Real Costs of Data Access Drivers
In the most basic sense, there are some fundamental aspects of data access that are complex to implement and rarely implemented (if at all) by free drivers. The list includes:
- Escape Syntaxes for Dates and Functions – abstraction for dates and function signatures at the application level (i.e., the same abstraction works across all compliant databases)
- Metadata Calls which enable smarter ODBC-compliant applications – this feature is typically missing on the Driver Side and abused on the Client side, i.e., clients are made DBMS specific by testing for specific DBMS names as opposed to utilizing metadata returned by drivers
- Scrollable Cursors – this is how you deal with change sensitivity and paging through large datasets. Some drivers actually fake support and get away with it due to a shortage of applications to test proper cursor types (Static, Forward-Only, Key-Set, Dynamic, and Mixed models).
Beyond driver sophistication, in regards to key feature implementations, let’s up the ante by veering into the area of data security. At the most basic level, It’s extremely important to understand that all data access drivers provide read-write access to your databases; thus, it’s imperative that data access drivers address the following:
- Read-Only or Read-Write Access modalities scoped to specific Users, specific User Groups, specific Databases, data access standard (ODBC, JDBC, or ADO.NET)-compliant applications, client host operating systems, and/or IP addresses or Ranges on your Network
- Any combination of the above as part of a configurable collection of data access rules (or policies).
Once you’re done with security, you then have the thorny issue of managing data access and data flow. In a nutshell, your driver needs to be able to handle:
- Protection against Cartesian Product-based network flooding (e.g., user queries Customer Table via an ODBC, JDBC, ADO.NET, OLE-DB compliant application without comprehension of back-end implications)
- Enabling or Disabling key DBMS engine data access optimization features (e.g., SQL RDBMS-specific extensions exposed via Environment Variables or SQL command-based settings)
- Conditional Connection Pooling across User, User Groups, Applications, Host Operating System, IP Address dimensions
- Data Encryption in Transit
Once you’ve dealt with Security and Data Flow, you then have to address enforcement of these settings across a myriad of ODBC-compliant hosts, which is where Zeroconf and centralized data access administration comes into play; i.e., configure once (locally) and enforce globally.
OpenLink Universal Data Access (UDA) Drivers
When OpenLink Software entered the ODBC Driver Market segment, circa 1992, the issues above were the fundamental basis of our Multi-Tier Drivers. Although the marketplace highlighted our drivers for their high performance, stability, and specification adherence – to all of which we remain committed – our fundamental engineering focus has always been skewed towards configurable data security, platform independence, and scalability.
Every item of concern outlined in the section above is addressed by security features built into our Multi-Tier (Enterprise Edition) Drivers. These features all leverage the fact that our multi-tier drivers include a sophisticated DB Session Rulebook that enables construction and enforcement of user attribute (user name, application, client operating system, IP address, target database, etc.)-based rules which are applied to all database sessions (single or pooled).
Today, in the year 2019, the security issues that pervade Native SQL RDBMS Drivers, as well as ODBC, JDBC, and ADO.NET Drivers/Providers, have only increased, courtesy of ubiquitous computing – facilitated by the Internet & Web, across desktop and mobile device dimensions. Paradoxically, there remains a fundamental illusion that all Data Access Drivers are made the same, that they simply provide you with the ability to connect to SQL RDBMS back-ends, for the industry standard price of $0.00, without consequence – thereby skewing the very nature of SQL RDBMS data access and its security and privacy implications.
I hope that this post brings some clarity to a very serious security and general configuration management issues associated with Data Access Drivers. Free ODBC Drivers offer nothing, that’s why they cost $0.00. When dealing with the real issues associated with Open Data Access, you must have a handle on the inevitable issues of data security and privacy.
Links