如何解释为什么 ODBC 需要数据库驱动程序
一个月前，我正在向一个朋友展示如何使用.NET来查询MySQL。它工作得很好，但他不明白为什么我们需要一个 MySQL 与 ODBC 结合的“驱动程序”。他认为 ODBC 就足够了。
当他问我为什么时，我尽力而为，但我的回答却不够。
这个问题的正确解释是什么？
A month ago, I was showing a buddy how use .NET to query MySQL. It worked just fine, but he didn't understand why we needed a "driver" for MySQL in conjunction with ODBC. He though ODBC would be enough.
When he asked me why, I did my best, but my answer came up short.
What is the correct explanation for this question?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您需要驱动程序的原因是 ODBC 本身并不是与数据库通信的驱动程序：它是一种抽象和 API。
本质上，它是一个 适配器 层，旨在使所有数据库对客户端应用程序显示相同：你说ODBC 库，它要求驱动程序管理器使用正确的数据库（基于您的连接字符串）满足您的请求。
为了使您的数据库品牌与 ODBC 兼容，它必须提供一个实现所需 API 的驱动程序，以便它可以使用 ODBC 功能服务来自客户端的请求。
The reason you need a driver is that ODBC is not in itself a driver for talking to databases: it's an abstraction and an API.
Essentially it is an adaptor layer designed to make all databases appear the same to the client application: you talk to the ODBC library, and it asks the driver manager to fulfill your request using the correct database (based on your connection string).
In order for your database brand to be compatible with ODBC therefore it must provide a driver which implements the required API in order that it can service requests from clients using the ODBC functions.
正如已经说过的，ODBC 是一个 API 和一个抽象层，而不是一个软件本身。
然而，前面的回答暗示 ODBC 驱动程序仅来自数据库供应商，这是不准确的。 ODBC 驱动程序有许多第三方来源，包括我自己的雇主。
许多数据库供应商将 ODBC 驱动程序及其引擎作为“复选框项”包含在内，因此他们可以声称支持 ODBC，但这些捆绑的驱动程序只是最小的实现和/或在某种程度上受到限制，以鼓励“本机”应用程序开发作为“高级”应用程序。 “ 选项。事实上，来自数据库供应商的 ODBC 驱动程序的性能通常远不如来自第三方供应商的 ODBC 驱动程序，两者都是故意的（因为如果数据库客户端应用程序被写入数据库的本机 API，则它们的用户将被锁定到该数据库引擎）和没有（许多数据库供应商根本不了解与数据库无关的 ODBC API 的细微差别，无法将其正确映射到特定于数据库的“本机”API）。这种锁定实际上并不符合数据库供应商的长期最佳利益（事实上，他们是 ODBC 最初开发的主要参与者），但短期业务目标有时会凌驾于长期愿景之上。
我的雇主 OpenLink Software 很久以前就认识到需要比较不同数据库、ODBC 驱动程序、操作系统和 DSN 连接属性的性能，并创建了一个开源基准实用程序 OpenLink ODBC Bench。该工具是跨平台的，可在您自己的环境中模拟 TPC-A 和 TPC-C 测试，以查看哪些组件最适合您的需求。作为一个开源项目，可以检查所有测试以确保在任何方向上都没有偏差，并且还可以根据您的特定部署的需要对它们进行扩展和调整。
当然，这一切都忽略了为什么要使用 .NET 中的 ODBC 驱动程序（这需要使用用于 ODBC 数据源的桥接 ADO.NET 提供程序，因此需要为双抽象进行额外的 API 转换）的问题，而不是直接通过 ADO.NET Provider for MySQL< /a>...
As has already been said, ODBC is an API and an abstraction layer, not a piece of software, per se.
However, the previous response implies that ODBC drivers come only from database vendors, and that's inaccurate. There are many third-party sources of ODBC drivers, including my own employer.
A number of database vendors include ODBC drivers with their engines as "checkbox items," so they can claim ODBC support, but those bundled drivers are minimal implementations and/or crippled in some way, to encourage "native" application development as the "superior" option. Indeed -- ODBC drivers from database vendors often perform far less well than ODBC drivers from third-party vendors, both with intent (because if database client applications are written to the database's native API, their users are locked-in to that database engine) and without (many database vendors simply don't understand enough about the nuances of the database-agnostic ODBC API to properly map it to their database-specific "native" API). Such lock-in isn't really in the database vendor's long-term best interests (in fact, they were major participants in the original development of ODBC), but short-term business goals sometimes override long-term vision.
My employer, OpenLink Software, long ago recognized that there was a need to compare performance across different databases, ODBC drivers, operating systems, and DSN connection attributes, and created an open-source benchmark utility, OpenLink ODBC Bench. This tool is cross-platform, and simulates TPC-A and TPC-C testing within your own environment, to see just which components are best suited to your needs. As an open source project, all tests may be inspected to ensure there is no skewing in any direction, and they may also be extended and adapted as needed for your specific deployment.
Of course, this all ignores the question of why you would use an ODBC Driver from .NET (which requires use of a bridging ADO.NET Provider for ODBC Data Sources, and thus an extra API translation for the double-abstraction), instead of going directly through an ADO.NET Provider for MySQL...
我发现该线程有点旧，但我想从所有 DBMS 的标准 odbc 驱动程序的视图中获得任何响应。我知道我们需要为每个 DBMS 提供单独的驱动程序。是否有可能有一个标准的 ODBC 驱动程序，可以在任何数据库引擎中无缝使用。我不认为不同的驱动程序在做一些与其他驱动程序完全不同的事情的能力方面存在很大差异
I see that the thread is bit old but i wanted to get any response on the view of a standard odbc driver for all DBMSs. I know that we need separate drivers for each DBMSs. Is it possible to have a standard ODBC driver which can be used seemlessly across any databases engines. I dont see a big difference between different drivers in terms of its ability to do something quite different than the other