一个月前，我正在向哥们展示如何使用.NET来查询MySQL。它工作得很好，但他不明白为什么我们需要MySQL的“驱动程序”和ODBC。他虽然ODBC就足够了。
当他问我为什么时，我尽了最大努力，但我的回答很短暂。
这个问题的正确解释是什么？
答案 0 :(得分：10)
您需要驱动程序的原因是ODBC本身不是与数据库通信的驱动程序：它是一个抽象和API。
本质上它是一个adaptor层，旨在使所有数据库看起来与客户端应用程序相同：您与ODBC库通信，并要求驱动程序管理器使用正确的数据库来完成您的请求（基于你的连接字符串）。
为了使您的数据库品牌与ODBC兼容，它必须提供一个实现所需API的驱动程序，以便它可以使用ODBC函数为客户端的请求提供服务。
答案 1 :(得分：4)
正如已经说过的，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驱动程序的问题（这需要使用桥接ADO.NET Provider for ODBC Data Sources，因此需要额外的API翻译用于双重抽象）而不是直接通过ADO.NET Provider for MySQL ......
答案 2 :(得分：0)
我看到该线程有点旧，但我想对所有DBMS的标准odbc驱动程序的视图得到任何响应。我知道每个DBMS都需要单独的驱动程序。是否可以使用标准的ODBC驱动程序，可以在任何数据库引擎中无缝使用。我不认为不同的驱动程序在执行与其他驱动程序完全不同的能力方面存在很大差异