常用数据库访问接口介绍(一)

一直很忙，虽然不知道在忙些什么。也有些烦心的事儿。但工作还是要做的，即使是为了给自己一个交代。数据库访问接口这些东西很烦，但有些东西无论你怎么努力都是绕不过去的，最终还是要回来。就像中国从制度上跳过了资本主义社会一样，还不是得回来补经济课！用了差不多3天左右的时间，查了60页左右的资料，总算大体上理清了一些眉目。

 

 

1 常见数据库访问接口

1.1 ODBC

    ODBC：开放式数据库互连（Open Database Connectivity），是微软公司推出的一种实现应用程序和关系数据库之间通讯的方法标准，是一个接口标准。所以它实际上是一种标准，符合标准的数据库就可以通过SQL语言编写的命令对数据库进行操作，但只能针对关系数据库进行操作（如SQL Server，Oracle，Access，Excel等），目前所有的关系数据库都符合该标准。ODBC本质上是一组数据库访问API（应用程序编程接口），由一组函数调用组成，核心是SQL语句。

    一个基于ODBC的应用程序对数据库进行操作时，用户直接将SQL语句传送给ODBC，同时ODBC对数据库的操作也不依赖任何DBMS，不直接与DBMS打交道，它将所有的数据库操作由对应的DBMS的ODBC驱动程序完成，由对应DBMS的ODBC驱动程序对DBMS进行操作。也就是说，不论是FoxPro、Access还是Oracle数据库，均可用ODBC API进行访问。由此可见，ODBC的最大优点是能以统一的方式处理所有的关系数据库。 具体见图1所示。

                                      图1 ODBC组件图

 

    在具体操作时，首先必须用ODBC管理器注册一个数据源，管理器根据数据源提供的数据库位置、数据库类型及ODBC驱动程序等信息，建立起ODBC与具体数据库的联系。这样，只要应用程序将数据源名提供给ODBC，ODBC就能建立起与相应数据库的连接。

    不过直接使用ODBC API比较麻烦，所以微软后来又发展出来DAO、RDO、ADO这些数据库接口，使用这些数据库接口开发程序更容易。这些接口都支持ODBC，所以即使你所访问的数据库没有提供ADO的驱动，只要有ODBC驱动一样可以使用ADO进行访问。但由图2可以看出，ODBC实际上是一种相当底层的访问技术，因此它可以从底层设置和控制数据库，完成一些高级数据库技术无法完成的功能。

                                 图2 ODBC网络结构图

 

 

1.2 DAO

   DAO：数据库访问对象（Database Access Object），所谓数据访问对象，顾名思义就是与数据库打交道，夹在业务逻辑层与数据资源层之间。是Microsoft一种用来访问Jet引擎的方法，主要适用于单系统应用程序或在小范围本地分布使用，访问所谓桌面数据库（如Access、FoxPro、dBase等）。DAO在设计时是专门用来处理MDB数据库的，由于其内部已经对Jet数据库的访问进行了加速优化，因此访问Access数据库时性能很好，也很方便，所以如果数据库是Access数据库且是本地使用的话，建议使用这种访问方式。它也可以通过ODBC访问远程数据库，但效率较低，一般不采用这种方式。它是第一个面向对象的数据库访问接口。DAO可以访问非关系型数据库。DAO的网络结构图和对象层次图分别如图3和图4所示。

                                    图3 DAO网络结构图

                                       图4 DAO对象层次图

 

 

1.3 RDO

   RDO：远程数据库对象（Remote Database Object）。为了弥补DAO访问远程数据库能力的不足，微软推出了RDO数据库访问接口，可以方便的用来访问远程数据库（网络数据库）。它封装了ODBC API的对象层，因此在访问ODBC兼容数据库时，具有比DAO更高的性能，而且比ODBC更易用。但同样由于这种和ODBC紧密的结合，使得它只能以ODBC的方式访问关系型数据库，同时也在访问Jet或ISAM数据库方面受到限制，而且无法访问非关系型数据库（？）。RDO提供了访问存储过程和复杂结果集的更多和更复杂的对象、属性以及方法，但它只是从DAO向ADO迈进的一个过度产品，在大多数情况下，ADO的性能都要优于它。RDO的网络结构图和对象层次图如图5和图6所示。

                                    图5 RDO网络结构图

 

 

图6 RDO对象层次图

 

1.4 OLE DB

OLE DB：数据库链接和嵌入对象（Object Linking and Embedding DataBase）。OLE DB是微软提出的基于COM思想且面向对象的一种技术标准，目的是提供一种统一的数据访问接口访问各种数据源，这里所说的"数据"除了标准的关系型数据库中的数据之外，还包括邮件数据、Web上的文本或图形、目录服务(Directory Services)、以及主机系统中的文件和地理数据以及自定义业务对象等。OLE DB标准的核心内容就是要求对以上这些各种各样的数据存储(Data Store)都提供一种相同的访问接口，使得数据的使用者(应用程序)可以使用同样的方法访问各种数据，而不用考虑数据的具体存储地点、格式或类型。

OLE DB 标准的具体实现是通过一组C++ API 函数， 就像ODBC 标准中的ODBC API 一样， 不同之处只是在于OLE DB 的API 是符合COM 标准、 基于对象的。由于OLE DB可以访问各种类型的数据源，包括关系型数据库，所以说，符合ODBC 标准的数据源是符合OLE DB标准的数据源的子集。但是符合ODBC的数据源要能够被OLE DB访问，符合OLE DB标准，还必须提供相应的OLE DB服务提供程序，就像SQL Server要符合ODBC标准,必须提供SQL Server ODBC驱动程序一样。实际上，微软已经为所有的ODBC数据源提供了一个统一的OLE DB服务程序，叫做Microsoft OLE DB Provider for ODBC drivers。这个东西允许你通过OLE-DB或ADO 访问ODBC提供的所有功能。换言之，ODBC和OLEDB这两种技术是互补的，不能完全互相替换。但在访问SQL Server数据库时，不通过ODBC驱动，而是通过一个专门的OLE DB Provider for SQL Server直接调用，具体参见图7（？）。对于非关系型数据源，只要它提供相应的OLE DB访问接口，就可以同其他关系型数据源一样进行操作。

ODBC OLE DB Provider发布之后，有人又担心ODBC Provider是不是在ODBC之上的新的层次？如果是，那么使用OLE DB访问ODBC数据源是否将影响性能？答案也是否定的。实际上，ODBC Provider的作用是替换ODBC Driver Manager，作为应用程序与ODBC驱动程序之间的桥梁，理论上不会增加任何开销。具体参见图1所示。