前言；前一段对数据库接口很困惑，于是在网上大量看有关文章，先整理如下，也有本人的一点见解，望大家多多批评，但是请说出您的见解，使我着片文章起到抛砖引玉的作用。

关键词：ODBC，OLEDB，ADO，DAO，RDO
题目：数据访问接口概论及其应用简介

主要内容：由于高级语言访问各种类型的数据源文件时，存在多种访问接口，关系复杂，优劣各异，本文就各种数据库访问接口做一总结比较，然后就目前常用的接口ADO的应用方法，及其内部各对象的灵活应用进行简单介绍。
正文：

第一节：数据访问接口的发展历程

早期的程序员在程序中要连接数据库是非常困难的，每种DBMS产生的数据库文件的格式都不一样，程序员要对他们访问的DBMS的底层API有相当程度的了解，通过API来访问特定的DBMS。这就产生了一个问题，当使用的DBMS改变后，或者用户习惯使用的DBMS与开发程序使用DBMS的不符合时，应用软件便无法正常访问DBMS。因此，能处理各种数据文件的API便产生了，这就是大家都知道的ODBC。
ODBC是通用API的早期产物，是基于结构查询语言 (sql) 的，以此作为访问数据的标准。这时大多数DBMS提供了面向ODBC的驱动程序，遵从了这个标准的DBMS被称为ODBC兼容的DBMS。ODBC兼容的数据库包括Access, MS-SQL Server, Oracle, Informix等。
但是ODBC并不完美，他虽然统一了对多种常用DBMS的访问，但是这个“访问”的过程是非常困难的，他仍然存在大量的低级调用，程序员必须将大量的精力放在底层的数据通信中，这是因为ODBC是面向C++的，而不能专注于所要处理的数据。为了改善这种及其不友好的接口，使得在程序开发中，数据库访问的工作更加容易，微软提出里一个解决方案：DAO (Data Access Objects),DAO的代码看起来是这样的：
objItem.AddNew
objItem.Name = "StudentDB"
objItem.Price = 10
objItem.Update
这说明他的代码更易于掌握，因为它更像是一种面向对象的语言，建立想要使用对象后，可以给他的各种属性赋值，提取各种属性的值，或者使用该对象提供的方法。总之，DAO是第一个面向对象的接口。
DAO 最适用于单系统应用程序或小范围本地分布使用。于是为了访问远程DBMS,更好地实现数据共享，或数据的交互操作，比如想要联接查询位于不同地方的主机中的两个数据表，这时产生了一个新的数据库访问接口：RDO(Remote Data Objects)，远程数据对象。
当然，RDO也是一个面向对象的接口。它同易于使用的 DAO style组合在一起，形式上展示出所有 ODBC 的底层功能和灵活性。RDO 已被证明是许多 SQL Server、Oracle 以及其他大型关系数据库开发者经常选用的最佳接口。RDO 提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性，以及方法。
说到这里，似乎事情已经解决，但是随着需求的发展，又引出了新的问题。以上各个数据库接口都需要数据以SQL(Structured Query Language)的格式存储，或者说，要求访问的数据文件都必须是关系类型的，也就是说产生这些文件的DBMS必须是关系数据库。而在平时，我们经常要处理一些菲关系数据源，例如Excel电子表格，有规则或无规则的文本文件，XML文件等。针对这个问题，微软提出了OLEDB,一个基于COM标准的数据存取对象。他能提供对所有数据类型的操作，甚至是没有规则的文本文件。
可能是由于两个原因，产生了ADO,微软最新的数据库接口。这两个原因是：1，为了大幅减少数据库访问工作量，提供一个更易于操作，更友好的接口。因为ADO是基于OLEDB的技术，他将OLEDB的功能封装，对用户透明。2，为了整合各种功能于一身，因为ADO时DAO和RDO的后继产物。包含在 DAO 和 RDO 模型中的许多功能被合并为单个对象，这样就生成了一个简单得多的对象模型。ADO “扩展”了 DAO 和 RDO 所使用的对象模型，这意味着它包含较少的对象、更多的属性、方法（和参数），以及事件。
另外简单提一下，还有一种数据访问接口ADO.NET。他是由ADO发展而来的，主要用于基于WEB的应用程序，善于处理XML类型的数据。

(作者hgj)
第二节 各种数据访问接口的关系

先简单概括一下：ODBC和OLEDB是底层的数据库接口，他们通过驱动程序访问数据文件，而DAO,RDO,ADO是上层数据库接口，他们向上与应用程序交互，向下与ODBC或OLEDB对话。另外，DAO也可以通过JET引擎访问数据文件。ADO是对OLEDB的封装。
关系图：

ODBC-OLEDB
OLE DB 标准的具体实现是一 组C++ API 函数， 就像ODBC 标准中的ODBC API 一样， 不同 的是，OLE DB 的API 是符合COM 标准、 基于对象的，而ODBC API 则是简单的C API。
当ODBC成为数据库接口的标准之后，大多数关系数据库都提供了面向ODBC的驱动程序，使得该类型的数据库文件可以被ODBC访问。前面说过，ODBC只可以访问任何支持SQL语言的关系型数据库，而OLEDB可以访问各种类型的数据源，包括关系型数据库，所以说，符合ODBC 标准的数据源是符合OLE DB标准的数据源的子集。那么，OLEDB是否可以取代ODBC呢？不会。符合ODBC的数据源要能够被OLE DB访问，符合OLE DB标准，还必须提供相应的OLEDB服务提供程序，叫做Microsoft OLE DB Provider for ODBC drivers。
现在，微软已经为所有的ODBC数据源提供了一个统一的OLEDB服务提供程序，这个东西允许你通过OLE-DB或ADO 访问ODBC提供的所有功能。换言之，ODBC和OLEDB这两种技术是互补的，不能完全互相替换。

DAO-ODBC
ODBC类只支持DML(Data Manipulation Language，数据操作语言)，不支持DDL，所以用ODBC类只能完成数据的操作，不能涉及数据库的结构。要执行DDL操作，只有通过ODBC API。ODBC API是数据库厂商为程序设计者提供的直接访问数据库的一组函数。注意：这里要指出的是，虽然ODBC API提供了很多很方便而且强大的功能，但是通常来说ODBC API都比较难学，而且使用很容易出错。支持DDL是DAO对数据库编程良好支持的一个重要体现。DDL(Data Definition Language)在SQL术语中叫做"数据定义语言"，它用来完成生成、修改和删除数据库结构的操作。
只要有ODBC驱动程序，DAO就可以访问ODBC数据源。二者都支持对各种ODBC数据源的访问。虽然二者使用的数据引擎不同，但都可以满足用户编写独立于DBMS的应用程序的要求。另外，DAO可以用Jet引擎访问两类数据库而无需通过ODBC驱动，一类是，*.MDB数据库，Microsoft Access 就是这类数据库，由于DAO是基于Microsoft Jet引擎的，因而在访问Access数据库(即*.MDB文件)时具有很好的性能。二类是，ISAM数据库，包括Btrieve、dBASEIII、dBASEIV、Microsoft FoxPro。

ADO-OLEDB
我们已经知道，OLE DB 标准的API是C++ API， 只能供C++ 语言调用（ 这也是OLE DB没有改名为ActiveX DB 的原因，ActiveX 是与语言无关的组件技术）。 为了使得流行的各种编程语言都 可以编写符合OLE DB 标准的应用程序， 微软在OLE DB API 之上， 提供了一种面向对象、 与语言无关的应用编程接口， 这就是ActiveX Data Objects， 简称ADO。简而言之，ADO就是将OLE DB的面向C++的复杂接口封装起来，提供了便于操作的接口。

ADO-DAO,RDO
ADO在编程难易程度方面比DAO和RDO都好 （主要得益于简单的对象模型）， 但是在利用数据库的特性方面与RDO 不相上下，但是ADO新版本的性能会比RDO更强。
与DAO，RDO模型的层次结构不同，ADO 基本上是一种平板结构：Command 和Recordset 与Connection 之间并没有上下层次关系。换一种说法，DAO或RDO 在定义Recordset对象时，必须先定义Connection对象，而ADO则可以不通过Connection而直接定义Recordset对象。
前面提到，ADO是DAO和RDO的后继产物，但是ADO目前还没有包含DAO的所有功能，目前的ADO并不支持数据定义语言(DLL),而我们已经知道DAO是支持DLL的。最终，Microsoft 承诺将提供一个 ADO DDL 部件来帮助进行 DAO 到 ADO 的移植，并为 OLE DB 供应商提供一般的 DDL 支持。
微软已公开表示，今后的微软产品数据访问的接口方面，将统一到OLE DB和ADO 标准上来。

ADO-ADO.NET
ADO使用OLE DB接口并基于微软的COM技术，而ADO.NET拥有自己的ADO.NET接口并且基于微软的.NET体系架构。这也就是说ADO.NET和ADO的数据访问方式是不同的。
在 ADO 中，数据的内存中表示形式为记录集Recordset,而在 ADO.NET 中，数据在内存中的形式为数据集Dataset。记录集看起来像单个表，如果要获得几个表的相关数据，必须使用 JOIN 查询。相反，数据集是一个或多个表的集合。这样，数据集可以模仿基础数据库的结构。
ADO 的运作是一种在线方式，他对数据的操作必须是实时的。ADO.NET则使用离线方式，在访问数据的时候ADO.NET会利用XML制作数据的一份幅本，ADO.NET的数据库连接也只有在这段时间需要在线。优点是效率高，在Web上，有上千个并行用户，系统资源是非常昂贵的。
(作者hgj)
第三节 数据访问接口的选择

经过上面的一系列分析，想必大家已经对什么时候用那种接口有了自己的理解，但是我还是想简单说一下我的看法。
如果你是一个新手，或者对其他方面的性能没有特别的要求，强烈建议你使用ADO,原因很简单，这是微软最新的访问技术，容易操作，有较好的前景。
如果你的应用程序是用C++写的，并且要求数据库存取迅速，你可以绕开ADO层，直接调用OLE DB或ODBC。但是这时你付出的代价是要操作更多的内部指令或对象属性。
如果要访问支持ODBC的数据库，而该数据库又在不支持OLE的服务器上，那么ODBC是最好的选择。例如，要访问位于linux服务器上的Oracle数据库。
ODBC在处理SQL时非常出众。处理非SQL数据库时，OLE-DB则具有非常明显的优势。
另外，在应用程序中要对数据库结构进行操作时，最好使用支持 DDL 的DAO。
另外还有一些深层的原因来决定用那种接口，作者能力有限，浅薄之处请见谅。
(作者hgj)
第四节 数据源的连接

先声明一下，这里的接口是以ADO为例的，数据库是以Access 或 SQL server为例，调用语言以VB为例。
在VB中添加ADO组件:工程-〉引用-〉Microsoft ActiveX Data Objects 2.8 library
大家知道，我们通常使用ADO对象的ConnectionString 属性来连接数据库的，那么怎样通过ConnectionString来连接呢？ConnectionString属性有四个参数，分别是：Provider, File name,Remote provider,Remote server 后两个是针对远程服务器的，也就是说，如果你的数据库位于本地计算机上，只要前两个参数就可以了，其中Provider指定用来连接的提供者名称，也可以作为connectionstring内部参数被赋值,见下。
连接数据库有多种方法，但从本质上分有两种：基于OLEDB和基于ODBC的。也许大家还听说过别的方法，例如：DSN,UDL,非DSN,字符串方法等，其实这些分法只不过是因connectionstring的参数信息放在不同的地方而已。下面详细分析。

UDL（数据连接文件）----- UDL-Less（连接字符串）
UDL数据连接文件是扩展名为*.udl的文件，是用来存放数据库连接信息的，UDL是针对OLEDB（直接的和面向ODBC的）的。以前在资源管理器里面单击右键-〉新建-〉microsoft数据连接，可以创建*.udl文件，不过现在不能用了。一般的方法是，新建一个*.txt文件，将扩展名改成*.udl,然后双击，就可以打开数据连接属性对话框，在这里你可以输入数据连接的相关信息，包括：OLEDB Provider,DSN/连接字符串，password,UserID 以及其他。
我们这里使用的数据是：Provider=Microsoft OLEDB Provider for ODBC Drivers
DSN=student（事先已建好，后面介绍，也可以使用连接字符串），User ID=yourname,Pass word=yourpassword
关闭连接属性对话框（你也可以在关闭之前点击“测试连接”按钮测试是否连接成功），现在使用该文件。
Dim DBconnect as New ADODB.connection
DBconnect.connectionstring="File Name=somepath/yourfile.udl" 'yourfile为你的udl文件的名称，somepath为你得udl文件的位置。
DBconnect.open

如果用记事本打开你的udl文件，会看到这样的字符串：
[oledb]
; Everything after this line is an OLE DB initstring
Provider=MSDASQL.1;Persist Security Info=False;User ID=yourname;Data Source=studentinfo

而所谓的UDL-Less就是不用udl文件，直接把参数值赋给connectionstring ,具体做法：
Dim DBconnect as New ADODB.connection
DBconnect.connectionstring="Provider=MSDASQL.1;User ID=yourname;Pass word=yourpassword;Data Source=studentinfo;"
DBconnect.open

connectionstring只有两个用于连接本地数据库的参数，那么其他的参数是怎么被处理的呢？有这么一句话，“任何其他参数将直接传递到提供者而不经过 ADO 处理”，我对这句话的理解是：
DSN（数据源名）-DSN-Less
这二者的区别主要是对基于ODBC的数据源而言的，因为DSN是针对ODBC数据源的。
建立数据源：控制面板-〉管理工具-〉数据源(ODBC),打开数据源管理器即可创建数据源，然后在connectionstring里面引用:
Dim DBconnect as New ADODB.connection
DBconnect.connectionstring="DSN=student;User ID=yourname;Pass word=yourpassword;"
DBconnect.open
DSN-Less和上面UDL-Less同理。

直接的连接字符串方式可能速度快一些，因为它提供所有的连接细节。udl数据链接文件方式需要从文件中读出连接细节，DSN方式需要从注册表中读取ODBC数据源的连接细节。

现在主要讨论：OLEDB和ODBC的字符串方法
这时，也许有人要问，本节开始不是说讨论的是ADO吗？怎么又要讨论OLEDB和ODBC？ADO只是一个顶层接口，用来和应用程序交互的，而向下它必须通过OLEDB或ODBC访问数据源。
OLEDB方法连接Access数据库
Dim DBconnect as New ADODB.connection
DBconnect.connectionstring="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=DBpath;"
DBconnect.open
ODBC方法连接Access数据库
Dim DBconnect as New ADODB.connection
DBconnect.connectionstring="DBQ=DBpath;Driver={Microsoft Access Driver (*.mdb)};"
DBconnect.open

这里的DBpath是你的数据库文件的存放路径,OLEDB方法要求给出数据提供程序Provider,ODBC方法要求给出数据驱动程序Driver。使用ODBC的方式要比OLE-DB的方式多一个层，因此，当访问相同的数据时，ODBC的方式可能会比OLE-DB速度慢一些。

数据源访问方式分类图：(作者hgj)