odbc与oledb，哪种技术速度快呀？oledb是在odbc之上的，为何性能竟然比odbc要高呢？该怎么处理
odbc与oledb，哪种技术速度快呀？oledb是在odbc之上的，为何性能竟然比odbc要高呢？
odbc与oledb，哪种技术速度快呀？oledb是在odbc之上的，为何性能竟然比odbc要高呢？
看了一些资料，都说 oledb的性能要好于 odbc,我非常不解。
因为odbc更接近底层呀。
对于odbc,是：
数据源-----odbc-----应用程序。
对于 oledb，是：
数据源-----odbc-----oledb-----应用程序
所以说，odbc更接近数据源呀，为何说 oledb 性能更高些呢？
------解决方案--------------------
翻了前几年的一个帖子，可能是下面这个原因：
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
------解决方案--------------------
odbc是致力于通用的数据库接口。。 对于某特定数据库。操作可能odbc就损性能。而其他的接口优化了方法。
------解决方案--------------------
oledb并非完全建立在odbc之上的.
------解决方案--------------------
基本概念全搞错了啊！
windows平台下主流数据库方式对比：
最快的，一种数据库本身提供的API。
其次，OLEDB，
再其次，ADO,
最后，ODBC。
ADO是建立在OLEDB之上的，OLEDB跟ODBC没有任何关系，不是建立在ODBC上的，
除非一种数据库没有提供OLEDB驱动，只有ODBC驱动，此时，通过OLEDB连数据库
可能是 OLEDB-〉ODBC-〉数据库。只有这种情况OLEDB才会慢于ODBC。
ODBC是一种传统C函数访问数据库的技术，用一些函数访问数据库的ODBC驱动，等于
DLL文件访问DLL文件，还要做很多多余工作为了通用性，所以慢。
OLEDB基于COM，本质是定义了一些空的接口，比如，连接数据的接口，关闭数据库的接口。
然后具体的OLEDB驱动实现这些接口，因此要比ODBC快。
ADO基于OLEDB，设计目的是供VB，脚步语言访问数据库。
结论，以VC开发数据库最好的方式是OLEDB，用ADO+VC是不适当的，但是比较简单。
ODBC是淘汰的技术，除非某种数据库只有ODBC驱动。
------解决方案--------------------
我觉得，没有免费的午餐
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
------解决方案--------------------
据我的知识，应该是odbc最快。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
------解决方案--------------------
ODBC API 本地连接MS SQL svr2000（SQLConnect）+ 关闭（SQLDisconnect）平均用时<连续500次测试> 为 35 毫秒/次
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的新型的数据库编程模型，但是ODBC API可算是一种很踏实的编程模型
odbc与oledb，哪种技术速度快呀？oledb是在odbc之上的，为何性能竟然比odbc要高呢？
看了一些资料，都说 oledb的性能要好于 odbc,我非常不解。
因为odbc更接近底层呀。
对于odbc,是：
数据源-----odbc-----应用程序。
对于 oledb，是：
数据源-----odbc-----oledb-----应用程序
所以说，odbc更接近数据源呀，为何说 oledb 性能更高些呢？
------解决方案--------------------
翻了前几年的一个帖子，可能是下面这个原因：
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
------解决方案--------------------
odbc是致力于通用的数据库接口。。 对于某特定数据库。操作可能odbc就损性能。而其他的接口优化了方法。
------解决方案--------------------
oledb并非完全建立在odbc之上的.
------解决方案--------------------
基本概念全搞错了啊！
windows平台下主流数据库方式对比：
最快的，一种数据库本身提供的API。
其次，OLEDB，
再其次，ADO,
最后，ODBC。
ADO是建立在OLEDB之上的，OLEDB跟ODBC没有任何关系，不是建立在ODBC上的，
除非一种数据库没有提供OLEDB驱动，只有ODBC驱动，此时，通过OLEDB连数据库
可能是 OLEDB-〉ODBC-〉数据库。只有这种情况OLEDB才会慢于ODBC。
ODBC是一种传统C函数访问数据库的技术，用一些函数访问数据库的ODBC驱动，等于
DLL文件访问DLL文件，还要做很多多余工作为了通用性，所以慢。
OLEDB基于COM，本质是定义了一些空的接口，比如，连接数据的接口，关闭数据库的接口。
然后具体的OLEDB驱动实现这些接口，因此要比ODBC快。
ADO基于OLEDB，设计目的是供VB，脚步语言访问数据库。
结论，以VC开发数据库最好的方式是OLEDB，用ADO+VC是不适当的，但是比较简单。
ODBC是淘汰的技术，除非某种数据库只有ODBC驱动。
------解决方案--------------------
我觉得，没有免费的午餐
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
------解决方案--------------------
据我的知识，应该是odbc最快。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
------解决方案--------------------
ODBC API 本地连接MS SQL svr2000（SQLConnect）+ 关闭（SQLDisconnect）平均用时<连续500次测试> 为 35 毫秒/次
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的新型的数据库编程模型，但是ODBC API可算是一种很踏实的编程模型