看了一些资料，都说 oledb的性能要好于 odbc,我非常不解。
因为odbc更接近底层呀。
对于odbc,是：
数据源-----odbc-----应用程序。
对于 oledb，是：
数据源-----odbc-----oledb-----应用程序
所以说，odbc更接近数据源呀，为何说 oledb 性能更高些呢？
17 个解决方案
#1
可能oledb对odbc做了某些优化
#2
翻了前几年的一个帖子，可能是下面这个原因：
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
#3
odbc是致力于通用的数据库接口。。 对于某特定数据库。操作可能odbc就损性能。而其他的接口优化了方法。
#4
我用的是oledb。。原理不懂。- -
#5
你这里说的oledb，是不是ADO?
#6
ado是建立在 oledb 之上的呀。
#7
oledb并非完全建立在odbc之上的.
#8
基本概念全搞错了啊！
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驱动。
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驱动。
#9
谢楼上老师指教。原来，并不是所有的oledb全是基于odbc呀。
oledb驱动与odbc驱动是平行的关系呀。
oledb驱动与odbc驱动是平行的关系呀。
#10
我觉得，没有免费的午餐
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
#11
据我的知识，应该是odbc最快。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
#12
楼主可以自己做个实验，然后把结果贴出来大家分享一下。
当然，得排除特殊优化（听说asp.net就对sql server有优化）或者是用数据库公司自己的api这些情况。
当然，得排除特殊优化（听说asp.net就对sql server有优化）或者是用数据库公司自己的api这些情况。
#13
看来，观点还是没有统一呀。
#14
评价一种数据库技术是否比另一种快或者更有效率，要综合比较。
比如：连接数据库速度，访问数据的速度，增加、插入、删除数据的速度，
大数据量访问数据的速度，对二进制字段的访问速度，访问存储过程的速度。
等等。
综合比较，OLEDB应该是除了API最快的数据库访问技术，其次是ADO,
ODBC也是一种底层访问技术，但早就不推荐了，所谓说OLEDB慢于ODBC，大概是
某种数据库没有原生OLEDB驱动的缘故，或者仅仅是比较了数据访问一项数据。
起码我做过数据库连接的测试。ODBC那是相当的慢。
#15
我曾做过2万行字符串读写，发现其实效率相差几乎可以忽略。
因此除非你数据量大到一定程序
因此除非你数据量大到一定程序
#16
ODBC API 本地连接MS SQL svr2000（SQLConnect）+ 关闭（SQLDisconnect）平均用时<连续500次测试> 为
35 毫秒/次
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的 新型的数据库编程模型，但是ODBC API可算是一种很 踏实的编程模型
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的 新型的数据库编程模型，但是ODBC API可算是一种很 踏实的编程模型
#17
偶尔看到这个帖子，挺有意思的，因为现在用java 开发了，用这些的机会很少很少了.看了那么多人 的回复觉得 r3000 的应该是回答最正确的，当然速度衡量标准不一定对，但是它把逻辑层次讲清楚了。
1.针对数据库本身提供的DB-API的操作肯定是 最快的，除非你自己有本事直接来处理和数据库交互的各种协议和数据。
2.ODBC是对各类关系数据库的一种封装，它是建立在DB-API之上的。
3.OLEDB是为了简化数据库操作和编程推出的COM接口，它既可以建立在DB-API上，也可以建立在ODBC上，更可以直接和DB交互（关系数据库很少有这样的OLE DB 驱动，但是我记得是有的）。
4.ADO 是OLE DB 进一步的封装，是为 类似于 VB（不是VB.net）、VBScript这种语言使用的（记得是说他们不是真正面向对象的语言，没有实现某个接口，而只能用最简单的自动化接口来实现了）
所以理论上讲有某个数据库的OLE DB的驱动，尤其是SQL Server，使用它是最能发挥数据库操作性能的，而且使用范围也广。现在因为离这些技术都很久了，没看到原来那种逻辑层次图可以 表明他们之间的关系，否则 一看就懂了。
1.针对数据库本身提供的DB-API的操作肯定是 最快的，除非你自己有本事直接来处理和数据库交互的各种协议和数据。
2.ODBC是对各类关系数据库的一种封装，它是建立在DB-API之上的。
3.OLEDB是为了简化数据库操作和编程推出的COM接口，它既可以建立在DB-API上，也可以建立在ODBC上，更可以直接和DB交互（关系数据库很少有这样的OLE DB 驱动，但是我记得是有的）。
4.ADO 是OLE DB 进一步的封装，是为 类似于 VB（不是VB.net）、VBScript这种语言使用的（记得是说他们不是真正面向对象的语言，没有实现某个接口，而只能用最简单的自动化接口来实现了）
所以理论上讲有某个数据库的OLE DB的驱动，尤其是SQL Server，使用它是最能发挥数据库操作性能的，而且使用范围也广。现在因为离这些技术都很久了，没看到原来那种逻辑层次图可以 表明他们之间的关系，否则 一看就懂了。
#1
可能oledb对odbc做了某些优化
#2
翻了前几年的一个帖子，可能是下面这个原因：
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
根据微软的说法, "ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象 ". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
#3
odbc是致力于通用的数据库接口。。 对于某特定数据库。操作可能odbc就损性能。而其他的接口优化了方法。
#4
我用的是oledb。。原理不懂。- -
#5
你这里说的oledb，是不是ADO?
#6
ado是建立在 oledb 之上的呀。
#7
oledb并非完全建立在odbc之上的.
#8
基本概念全搞错了啊！
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驱动。
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驱动。
#9
谢楼上老师指教。原来，并不是所有的oledb全是基于odbc呀。
oledb驱动与odbc驱动是平行的关系呀。
oledb驱动与odbc驱动是平行的关系呀。
#10
我觉得，没有免费的午餐
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
多年前，我测试过ODBC API 和OleDB的性能，感觉ODBC API性能上明显优越些
ODBC API 提供极为简单的数据交换，简单常常意味可以订制得很高效，当然需要写很多重复代码
有一种误解：ODBC API 和MFC ODBC 数据库类组是一回事，显然它们完全不是一回事！
#11
据我的知识，应该是odbc最快。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
oledb我不熟悉，没用过。
拿ado来说，它硬是实现了一个类似高级语言里面的好像是无数据类型的数据类型（就是所有数据都可以往里扔），这都是通过类去实现的，重载了各种操作符。
这肯定不如odbc这种全是简单数据类型的来得快。
当然，最快的还是数据库公司自己操作的api，比如orcale的oci，mysql也提供类似的。相信这种方法不在本文的讨论之列。
#12
楼主可以自己做个实验，然后把结果贴出来大家分享一下。
当然，得排除特殊优化（听说asp.net就对sql server有优化）或者是用数据库公司自己的api这些情况。
当然，得排除特殊优化（听说asp.net就对sql server有优化）或者是用数据库公司自己的api这些情况。
#13
看来，观点还是没有统一呀。
#14
评价一种数据库技术是否比另一种快或者更有效率，要综合比较。
比如：连接数据库速度，访问数据的速度，增加、插入、删除数据的速度，
大数据量访问数据的速度，对二进制字段的访问速度，访问存储过程的速度。
等等。
综合比较，OLEDB应该是除了API最快的数据库访问技术，其次是ADO,
ODBC也是一种底层访问技术，但早就不推荐了，所谓说OLEDB慢于ODBC，大概是
某种数据库没有原生OLEDB驱动的缘故，或者仅仅是比较了数据访问一项数据。
起码我做过数据库连接的测试。ODBC那是相当的慢。
#15
我曾做过2万行字符串读写，发现其实效率相差几乎可以忽略。
因此除非你数据量大到一定程序
因此除非你数据量大到一定程序
#16
ODBC API 本地连接MS SQL svr2000（SQLConnect）+ 关闭（SQLDisconnect）平均用时<连续500次测试> 为
35 毫秒/次
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的 新型的数据库编程模型，但是ODBC API可算是一种很 踏实的编程模型
远程连接 + 关闭 <同城，上海ADSL，服务器在IDC> 274 毫秒/次
有兴趣的朋友可以测试一下OleDB 的连接性能
至于数据库操作，本人觉得，ODBC 模型简单,对于存储设计有较大余地
一般说，OleDB 是推荐的 新型的数据库编程模型，但是ODBC API可算是一种很 踏实的编程模型
#17
偶尔看到这个帖子，挺有意思的，因为现在用java 开发了，用这些的机会很少很少了.看了那么多人 的回复觉得 r3000 的应该是回答最正确的，当然速度衡量标准不一定对，但是它把逻辑层次讲清楚了。
1.针对数据库本身提供的DB-API的操作肯定是 最快的，除非你自己有本事直接来处理和数据库交互的各种协议和数据。
2.ODBC是对各类关系数据库的一种封装，它是建立在DB-API之上的。
3.OLEDB是为了简化数据库操作和编程推出的COM接口，它既可以建立在DB-API上，也可以建立在ODBC上，更可以直接和DB交互（关系数据库很少有这样的OLE DB 驱动，但是我记得是有的）。
4.ADO 是OLE DB 进一步的封装，是为 类似于 VB（不是VB.net）、VBScript这种语言使用的（记得是说他们不是真正面向对象的语言，没有实现某个接口，而只能用最简单的自动化接口来实现了）
所以理论上讲有某个数据库的OLE DB的驱动，尤其是SQL Server，使用它是最能发挥数据库操作性能的，而且使用范围也广。现在因为离这些技术都很久了，没看到原来那种逻辑层次图可以 表明他们之间的关系，否则 一看就懂了。
1.针对数据库本身提供的DB-API的操作肯定是 最快的，除非你自己有本事直接来处理和数据库交互的各种协议和数据。
2.ODBC是对各类关系数据库的一种封装，它是建立在DB-API之上的。
3.OLEDB是为了简化数据库操作和编程推出的COM接口，它既可以建立在DB-API上，也可以建立在ODBC上，更可以直接和DB交互（关系数据库很少有这样的OLE DB 驱动，但是我记得是有的）。
4.ADO 是OLE DB 进一步的封装，是为 类似于 VB（不是VB.net）、VBScript这种语言使用的（记得是说他们不是真正面向对象的语言，没有实现某个接口，而只能用最简单的自动化接口来实现了）
所以理论上讲有某个数据库的OLE DB的驱动，尤其是SQL Server，使用它是最能发挥数据库操作性能的，而且使用范围也广。现在因为离这些技术都很久了，没看到原来那种逻辑层次图可以 表明他们之间的关系，否则 一看就懂了。