ADO,OLEDB,ODBC,DAO,RDO的区别

ODBC(Open Database Connectivity，开放数据库互连)是微软公司开放服务结构(WOSA,Windows Open Services Architecture)中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。这些API利用SQL来完成其大部分任务。ODBC本身也提供了对SQL语言的支持，用户可以直接将SQL语句送给ODBC。---出现的最早，但不总是万能。

DAO：数据访问对象是用来显露了Microsoft Jet数据库引擎（最早是给Microsoft Access 所使用，现在已经支持其它数据库），并允许开发者通过ODBC直接连接到其他数据库一样，直接连接到 Access 表。DAO 最适用于单系统应用程序或在小范围本地分布使用。其内部已经对Jet数据库的访问进行了加速优化，而且其使用起来也是很方便的。所以如果数据库是Access数据库且是本地使用的话，建议使用这种访问方式---应用的专一性

RDO（Remote Data Objects）远程数据对象是一个到ODBC的、面向对象的数据访问接口，它同易于使用的DAO style组合在一起，提供了一个接口，形式上展示出所有ODBC的底层功能和灵活性。尽管RDO在很好地访问Jet或ISAM数据库方面受到限制，而且它只能通过现存的ODBC驱动程序来访问关系数据库。但是，RDO已被证明是许多SQL Server、Oracle 以及其他大型关系数据库开发者经常选用的最佳接口。RDO提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性，以及方法。---无疑是在odbc基础上的

OLE DB 是 Microsoft 的一个战略性系统级编程接口，用于管理整个组织内的数据。OLE DB 是建立在 ODBC 功能之上的一个开放规范。ODBC 是为访问关系型数据库而专门开发的，OLE DB 则用于访问关系型和非关系型信息源，例如主机 ISAM/VSAM 和层次数据库，电子邮件和文件系统存储，文本、图形和地理数据以及自定义业务对象。
OLE DB 定义了一组 COM 接口，对各种数据库管理系统服务进行封装，并允许创建软件组件，实现这些服务。OLE DB 组件包括数据提供程序（包含和表现数据）、数据使用者（使用数据）和服务组件（处理和传送数据，例如，查询处理器和游标引擎）。
OLE DB 接口有助于平滑地集成组件，这样，OLE DB 组件厂商就可以快速地向市场提供高质量 OLE DB 组件。此外，OLE DB 包含了一个连接 ODBC 的“桥梁”，对现用的各种 ODBC 关系型数据库驱动程序提供一贯的支持。---号称取代odbc，但也兼容odbc

ADO（ActiveX Data Object）是DAO/RDO的后继产物。ADO 2.0在功能上与RDO更相似，而且一般来说，在这两种模型之间有一种相似的映射关系。ADO"扩展"了DAO和 RDO 所使用的对象模型，这意味着它包含较少的对象、更多的属性、方法（和参数），以及事件。 作为最新的数据库访问模式，ADO的使用也是简单易用，所以微软已经明确表示今后把重点放在ADO上，对DAO/RDO不再作升级，所以ADO已经成为了当前数据库开发的主流。 ADO涉及的数据存储有DSN(数据源名称)、ODBC（开放式数据连接）以及OLE DB三种方式。后面的例程将详细讲解这三种方式的具体访问实现。---可以说是对odbc，oledb这些系统级的编程接口的汇接，并对DAO,RDO这些应用级的编程接口的升级吧。

OLEDB的性能比较

有许多种办法可以连上一个数据库. 你可以用System DSN, DSN-less连接或是本地的OLEDB provider. OLEDB? 这是什么什么玩艺儿? 也许你们中的许多人以前没有听说过. 要回答这个问题,我们先得回顾一下数据库连接的历史.

早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
ODBC兼容的数据库包括Access, MS-SQL Server, Oracle, Informix等.

但ODBC并不是完美无缺的,它仍然含有大量的低级的调用,开发ODBC应用程序仍较困难. 开发者不得不将大量的精力花在底层的数据库通信中,而不能专注于他们所要处理的数据. 后来微软提出了一个解决方案: DAO(Data Access Objects). DAO的代码看起来象这样:

objItem.AddNew
objItem.Name = "Chair"
objItem.Price = 10
objItem.Update

你也许看过DAO的代码. 后来DAO演变为RDO(Remote Data Objects, 为分布式数据库体系设计), 再后来是ADO. 尽管它们都有各自的不足之处. 根据微软的说法,"ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).

OLEDB位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的"应用程序". 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升. 那我们该如何直接连接到OLEDB呢?

要想直接连到OLEDB层,你必须改变你的connection对象连接字符串. 先用老办法创建一个connectiong对象:

Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")

接下去,我们不用常规的类似DSN=pubs or DRIVER={MS SQL-
Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine的连接字符串,而采用下面的连接字符串:

objConn.ConnectionString = "Provider=ProviderName; Data
Source=DatabaseSource; Initial Catalog=DatabaseName; User ID=UserID;
Password=Password"

对于SQL:
ProviderName = SQLOLEDB
Data Source = Server Name
Initial Catalog = Database Name

对于Access:
ProviderName = Microsoft.Jet.OLEDB.3.51
Data Source = Full path to .MDB file

下面让我们来看两个例子,一个是针对Access的,还有一个是针对SQL的. 如果你的连接SQL的DSN-less连接串是这样的:

DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine

那么直接连接到OLEDB的连接字符串应该是这样的:

Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; User
ID=sa; Password=

让我们来看看Access,如果你的Access的连接字符串是:

DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=c:\inetpub\wwwroot\users.mdb

那么直接连接到OLEDB的连接字符串应该是这样的:

Provider=Microsoft.Jet.OLEDB.3.51; Data
Source=c:\inetpub\wwwroot\users.mdb

就是这么简单,挺棒的吧?

这很重要吗?
现在你也许对为什么要学习这种新的数据库连接方法感到有些儿迷惑,为什么不走标准的DSN-less/System DSN路子呢? 让我来告诉你为什么. 据Wrox出的ADO 2.0
Programmer's Reference一书中的测试,用OLEDB连接而不是DSN或DSN-less的连接会得到的性能提升如下:

性能比较
SQL Access
　OLEDB DSN　OLEDB DSN
Connection Times: 18 82 Connection Times: 62 99
Iterating through 1,000 Records Times: 2900 5400 Iterating through
1,000 Records Times: 100 950