OLE DB 的概念
OLE DB 的概念
简单地说，OLE DB 是一种技术标准，目的是提供一种
统一的数据访问接口，这里所说的“数据”，除了标准的关系型数据库中的数据之外，还包括邮件数据、Web 上的文本或图形、目录服务（Directory Services），以及主机系统中的IMS 和VSAM 数据。OLE DB 标准的核心内容就是要求以上这些各种各样的数据存储（Data Store）都提供一种相同的访问接口，使得数据的使用者（应用程序）可以使用同样的方法访问各种数据，而不用考虑数据的具体存储地点、格式或类型。
OLE DB
标准的具体实现是一组C++ API
函数，就像
ODBC
标准中的ODBC API 一样，不同的是，
OLE DB
的API
是符合COM
标准、基于对象的（ODBC API
则是简单的C API
）。使用OLE DB API，可以编写能够访问符合OLE DB 标准的任何数据源的应用程序，也可以编写针对某种特定数据存储的查询处理程序（Query Processor）和游标引擎（Cursor Engine），因此OLE DB 标准实际上是规定了数据使用者和提供者之间的一种应用层的协议（Application-Level Protocol）。
即将发布的微软最新数据库产品SQL Server 7.0 的查询处理程序就是使用OLE DB API 编写的，所以在SQL Server 7.0 的Transact-SQL 语法中，可以支持异种数据库的查询，当然，这些异种数据库必须也提供相应的OLE DB 访问接口。
OLE DB 标准中定义的新概念
OLE DB 将传统的数据库系统划分为多个逻辑组件，这些组件之间相对独立又相互通信。这种组件模型中的各个部分被冠以不同的名称：
数据提供者（Data Provider）。提供数据存储的软件组件，小到普通的文本文件、大到主机上的复杂数据库，或者电子邮件存储，都是数据提供者的例子。有的文档把这些软件组件的开发商也称为数据提供者。
数据服务提供者（Data Service Provider）。位于数据提供者之上、从过去的数据库管理系统中分离出来、独立运行的功能组件，例如查询处理器和游标引擎（Cursor Engine），这些组件使得数据提供者提供的数据以表状数据（Tabular Data）的形式向外表示（不管真实的物理数据是如何组织和存储的），并实现数据的查询和修改功能。SQL Server 7.0 的查询处理程序就是这种组件的典型例子。
业务组件（Business Component）。利用数据服务提供者、专门完成某种特定业务信息处理、可以重用的功能组件。分布式数据库应用系统中的中间层（Middle-Tier）就是这种组件的典型例子。
数据消费者（Data Consumer）。任何需要访问数据的系统程序或应用程序，除了典型的数据库应用程序之外，还包括需要访问各种数据源的开发工具或语言。
OLE DB 与ODBC 的关系
由于OLE DB 和ODBC 标准都是为了提供统一的访问数据接口，所以曾经有人疑惑：OLE DB 是不是替代ODBC 的新标准？答案是否定的。实际上，
ODBC
标准的对象是基于SQL
的数据源（SQL-Based Data Source
），而OLE DB
的对象则是范围更为广泛的任何数据存储。从这个意义上说，符合ODBC 标准的数据源是符合OLE DB 标准的数据存储的子集。符合ODBC 标准的数据源要符合OLE DB 标准，还必须提供相应的OLE DB 服务程序（Service Provider），就像SQL Server 要符合ODBC 标准，必须提供SQL Server ODBC 驱动程序一样。现在，微软自己已经为所有的ODBC 数据源提供了一个统一的OLE DB 服务程序，叫做ODBC OLE DB Provider。
ODBC OLE DB Provider 发布之后，有人又担心：ODBC Provider 是不是在ODBC 之上的新的层次（Layer）？如果是，那么使用OLE DB 访问ODBC 数据源是否将影响性能？答案也是否定的。实际上，
ODBC Provider
的作用，是替换ODBC Driver Manager
，作为应用程序与ODBC
驱动程序之间的桥梁，理论上不会增加任何开销。
ADO 的概念
我们已经知道，
OLE DB
标准的API
是C++ API
，只能供C++
语言调用（这也是OLE DB 没有改名为ActiveX DB 的原因，ActiveX 是与语言无关的组件技术）。为了使得流行的各种编程语言都可以编写符合OLE DB 标准的应用程序，
微软在
OLE DB API
之上，提供了一种面向对象、与语言无关的（Language-Neutral
）应用编程接口，这就是ActiveX Data Objects
，简称ADO。
与DAO、RDO 等类似，ADO 实际上是一种对象模型，不过这个对象模型相对简单，示意如下：
在这个对象模型中，Connection 类似于RDO 的rdoConnection 或者DAO 的Database，Command 类似于RDO 的rdoPreparedStatement 或者DAO 的QueryDef。
值得注意的是：与DAO 等模型的层次结构不同，ADO 基本上是一种平板结构：Command 和Recordset 与Connect 之间并没有上下层次关系，这种设计主要是为了适应Internet 应用开发的需要。因为在Internet 上，像在局域网内那样维护一个永久性的连接、然后在连接的基础上执行查询，基本上是不可能的。
ADO 与其他编程接口的比较
网络数据库应用程序的开发可以使用的编程接口包括：DAO、ADO、RDO、ODBC API 和DB-Library 等，应用系统的框架模型示意如下：
除了这些标准的编程接口之外，还有一些应用程序（例如MS Access）也可以作为访问远程数据库的编程工具。这些接口或工具在编程的简便程度和利用远程数据库的功能方面差异很大，如下图所示：
可以看出，使用MS Access（通过DAO/JET），编程非常容易，但是因为把远程网络数据库当成本地Access 数据库对待，很难利用网络数据库的高级特性；而ODBC API 则刚好相反，数据库管理系统的特性几乎可以完全利用，但是编程复杂，效率低。
我们关心的ADO 在编程难易程度方面比DAO 和RDO 都好（主要得益于简单的对象模型），但是在利用数据库的特性方面与RDO 不相上下；至于程序运行效率，ADO 当前的版本是1.5，性能方面与RDO 还有一定的差距，当Visual Studio 6 发布时，ADO 将升级到2.0 版，新版本在功能和性能方面都将与RDO 相当或更强。因此对于应用开发人员来说，ADO 是一种非常有前途的编程接口。
实际上，微软已经公开表示，今后的微软产品在数据访问的接口方面，将统一到OLE DB 和ADO 标准上来。
ADO 编程实例
对于习惯了使用DAO 或RDO 的编程人员来说，ADO 的出现无疑会有一定的冲击，因为新的对象模型总是需要一个学习的过程。但实际上，对于最常用的数据库访问操作，这些接口往往只是在对象的名称、属性和方法上略有不同而已，所以广大程序员不必担心。下面举例说明应用方法。
（1）连接/ 打开数据库
使用ADO：
Dim CnADO As New ADODB.Connection
Dim sConn As String
sConn = "Driver={SQL Server};Server=MyServer"
sConn = sConn & ";UID=sa;PWD=;Database=pubs"
sConn = sConn & ";Network=DBMSSOCN;Address=MyServer,1433"
CnADO.Open sConn
使用RDO：
Dim Env As rdoEnvironment
Dim CnRDO As rdoConnection
Dim sConn As String
Set Env = rdoEngine.rdoEnvironments(0)
sConn = "Driver={SQL Server};Server=MyServer"
sConn = sConn & ";UID=sa;PWD=;Database=pubs"
sConn = sConn & ";Network=DBMSSOCN;Address=MyServer,1433"
Set CnRDO = Env.OpenConnection("", , , sConn)
（2）查询结果集
使用ADO：
Dim Rs As ADODB.Recordset
Set Rs = CnADO.Execute("select * from titles")
使用RDO：
Dim Rs As rdoResultset
Set Rs = CnRDO.OpenResultset("select * from titles")
可见，两种方法几乎完全一样，而且ADO 在有些方面更加简单（例如创建数据库连接时不用先指定一个上层对象—RDO 的rdoEnvironment）。