OLE DB数据库访问技术

 

OLE DB数据库访问技术

 

有许多种办法可以连上一个数据库. 你可以用 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

ADO 与ADO.NET

 

1. ADO与ADO.NET简介

ADO与ADO.NET既有相似也有区别，他们都能够编写对数据库服务器中的数据进行访问和操作的应用程序，并且易于使用、高速度、低内存支出和占用磁盘空间较少，支持用于建立基于客户端/服务器和 Web 的应用程序的主要功能。但是ADO使用OLE DB接口并基于微软的COM技术，而ADO.NET拥有自己的ADO.NET接口并且基于微软的.NET体系架构。众所周知.NET体系不同于COM体系，ADO.NET接口也就完全不同于ADO和OLE DB接口，这也就是说ADO.NET和ADO是两种数据访问方式。

 

2. 数据访问方式的历史

下面简单的回顾一下微软的数据访问方式所走过的几个阶段。

ODBC – （Open Database Connectivity）是第一个使用SQL访问不同关系数据库的数据访问技术。使用ODBC应用程序能够通过单一的命令操纵不同的数据库，而开发人员需要做的仅仅只是针对不同的应用加入相应的ODBC驱动。

DAO - （Data Access Objects）不像ODBC那样是面向C/C++程序员的，它是微软提供给Visual Basic开发人员的一种简单的数据访问方法，用于操纵Access数据库。

RDO – 在使用DAO访问不同的关系型数据库的时候，Jet引擎不得不在DAO和ODBC之间进行命令的转化，导致了性能的下降，而RDO（Remote Data Objects）的出现就顺理成章了。

OLE DB – 随着越来越多的数据以非关系型格式存储，需要一种新的架构来提供这种应用和数据源之间的无缝连接，基于COM（Component Object Model）的OLE DB应运而生了。

ADO – 基于OLE DB之上的ADO更简单、更高级、更适合Visual Basic程序员，同时消除了OLE DB的多种弊端，取而代之是微软技术发展的趋势。

 

. ADO与ADO.NET对照

在开始设计.NET体系架构时，微软就决定重新设计数据访问模型，以便能够完全的基于XML和离线计算模型。两者的区别主要有：

ADO以Recordset存储，而ADO.NET则以DataSet表示。Recordset看起来更像单表，如果让Recordset以多表的方式表示就必须在SQL中进行多表连接。反之，DataSet可以是多个表的集合。ADO 的运作是一种在线方式，这意味着不论是浏览或更新数据都必须是实时的。ADO.NET则使用离线方式，在访问数据的时候ADO.NET会利用XML制作数据的一份幅本，ADO.NET的数据库连接也只有在这段时间需要在线。

由于ADO使用COM技术，这就要求所使用的数据类型必须符合COM规范，而ADO.NET基于XML格式，数据类型更为丰富并且不需要再做COM编排导致的数据类型转换，从而提高了整体性能。