比较ADO与ODBC的区别

       有很多种使用数据库的方法，对大多数数据库来说，选择C++这种产品也许并不适宜。我们知道，像dBASE IV，FoxPro，Oracle和Access这样的产品是完全以数据库管理为中心的。事实上，这些产品非常善于创建数据库管理器，以至于它们确实并不善于做太多其它的工作。即使要用更通用化而非更专用化的数据库产品来执行一些类型的工作，在使程序设计更容易这一方面，像VisualBasic和Delphi这样的RAD(Rapid Application Develop(快速应用开发)环境也要比Visual C++强很多。 

       你是不是对我的说法感到很奇怪？下面我就要谈一谈，在谈到使用数据库管理系统(DBMS)这个话题时，用Visual C++实际上可以做些什么。虽然上述其它语言使得编写成熟的包括用户界面和高速搜索能力的DBMS就像孩子做游戏一样容易，但是，它们缺少Visual C++可以提供的某些重要东西。你不能为使用Access的数据库轻松地编写出实用程序。正像实用程序的定义所说的，实用程序应该很小并且具备可移植性——Access应用程序却不是这样。即使用Access这样的产品创建的程序可以很小并且可以移植，你仍有其它方面的需求：底层的功能。 

注：编写数据库实用程序及驱动程序时，可以选择Visual C++语言。 

        想像一下，使用像Visual Basic这样的语言来与实时数据采集设备打交道的情况。在进行底层访问时，RAD的保护环境常常使程序员不能进行有效的处理。当然，数据采集设备几乎不依赖于简明的连接。你打算如何把Visual Basic和外部的数据源连接起来呢？数据源甚至可能不了解Windows，DOS或类似的成熟的操作系统。 

        只要使用得当，很容易看到Visual C++是一种不可或缺的数据库管理工具。针对大规模的应用程序，即使你仍想依赖于Visual Basic这样的RAD语言，也请考虑一下Visual C++，它创建的程序规模小、提供底层访问并能提供实时访问。事实上，你可能还没有想到，Visual C++数据库应用程序的市场是很有潜力的。随着人们在旅途中越来越多地使用膝上型和掌上型电脑，这两类电脑上的数据库应用程序也变得越来越普通。你也许能够适应今天的膝上型电脑上的Access应用程序，但谈到硬盘大小或内存需求时，公司里较老的膝上型电脑可能就达不到要求。运行Windows CE的掌上型电脑在运行这个Access应用程序时，肯定会发生故障。在这一数据库市场的新领域，Visual C++提供了无价无限的工具。 

        Web链接 谈到使用Visual C++和数据库，其实你并不孤单。从一开始就有数据库专用新闻组提供有关数据库创建技巧的帮助，比如microsoft.public.access。不过，这些新闻组提供的是通用信息，对实际编写应用程序并非全都那么有用。专门针对Visual C++问题的新闻组是microsoft.public.vc.database和microsoft.public.vc.mfcdatabase。如果你决定用ODBC访问数据库，可能还要查看一下microsoft.public.odbc.sdk新闻组，它讨论的不仅仅是SDK(Software Development Kit,软件开发工具包) 。对最新技术感兴趣的程序员可以查阅microsoft.public.ado新闻组，或者microsoft.public.oledb（对象链接和嵌入数据库）新闻组，前者讨论 ADO，后者讨论ADO的基础技术。在microsoft.public.ado.rds有一个ADO子组，它讨论远程数据访问。 

既然所有的疑惑都消除了，大多数人的信心也就增强了，下面我们就介绍两种使C++访问数据库中的数据的主要方法：ODBC（开放数据库互连）和ADO（ActiveX数据对象）。在本章中，将介绍这两种类型的访问方法，但我想你会发现，ADO方法是针对新的程序设计情形而采用的。它克服了早期技术的诸多限制，依赖于Microsoft新的底层访问方法OLE-DB（对象链接和嵌入数据库）。在本书的后面我们会看到，用ADO和Visual C++提供的各种向导来汇集数据库工程，其速度有多快。 

注 ODBC通常用来访问不具备OLE-DB特性的非Microsoft数据库中的数据；16位的ODBC驱动程序工作起来可能非常缓慢。 

ODBC素以最慢的数据访问方法而著称，但是很可惜，当ADO或DAO都不支持某个数据库管理器而ODBC支持这个数据库管理器时，在这种特定的情形下，你仍然需要使用ODBC。在大多数情况下，这意味着要从数据库厂商那里获得所需的驱动程序，虽然Visual C++确实附带了一些产品的驱动程序（如果你正在使用数据库管理器的某些神秘功能，那么就需要建立自己的接口枣这并不是一件十分困难的事）。本质上讲，你总是要使用ODBC来访问Microsoft产品之外的其它DBMS产品所创建的数据库，这些数据库并不具备OLE-DB功能。ODBC还要求做一些额外的工作枣为ADO调整Visual C++中的大部分向导。 

高级技巧 

除了使用ADO和ODBC外，你还可以使用像DAO（数据访问对象）这样的早期技术，该技术包含在像Access这样的Microsoft产品中。DAO依赖于用Microsoft Access自动获得的Microsoft Jet数据库引擎。DAO还是较早版的Visual Basic所使用的引擎（最新版的Visual Basic和Visual C++依赖于相同的ADO/OLE-DB组合），所以如果需要支持较早的Visual Basic应用程序，那么DAO仍是一个不错的选择。 

尽管Microsoft文件声明，可以用DAO访问非Microsoft产品建立的数据库，但你仍会发现，在这种情况下，使用ADO和ODBC要好得多。这样的话，不但兼容性问题会少一些，速度也将有所提高，因为数据请求经过的接口层减少了。有一条经验要记住，DAO是设计用来处理MDB文件的。 

ADO的一个问题是，它不支持远程通信。这是Microsoft提出RDO（Remote Data Object,远程数据对象）的原因之一。这种特别技术在Visual Basic应用程序中的使用，要比在Visual C++中的使用多得多，所以我猜想，你们中有很多人都在使用它。但是，记住RDO仍是一种生命力很强的技术，这一点很重要。ADO确实具有替代RDO的远程数据服务(RDS)特征。换言之，ADO在一个软件包中提供了DAO和RDO两种功能性。 
另:用ADO连接数据库的三种方式及性能比较:


    

        

            

            

            
用ADO连接数据库的三种方法及其性能比较
            
            

        
        

            

            

ADO连接数据库通常有三种方法：System DSN Connection，DSN-less Connection 和 OLE DB Connection，这是大家都很熟悉的，它们的使用方法如下：
            
(注：三种方法的区别在于使用的是哪个关键字 - DSN,Driver,Data Source,Provider。UID，PWD 是 ODBC 的标记，User ID,Password 是 OLEDB 的标记。特别指出的是 Data Source 在 ODBC 标记中表示数据源，等同于 DSN，在 OLEDB 标记中表示服务器名或数据库名。) 
            
'System DSN Connection
Set cnn = Server.CreateObject("ADODB.Connection")
cnn.Open "DSN=your_dsn;UID=user_name;PWD=password;"
'或者用 OLEDB 标记
cnn.Open "Data Source=your_dsn;User ID=user_name;Password=password;"

'DSN-less Connection
'以SQL Server为例
Set cnn = Server.CreateObject("ADODB.Connection")
cnn.Open "driver={SQL Server};server=server_name;uid=user_name;pwd=pwd;database=pubs"
            
'OLE DB Connection
'以SQL Server为例
Set cnn = Server.CreateObject("ADODB.Connection")
cnn.Open "provider=sqloledb;data source=server_name;initial catalog=pubs;user id=user_name;password=pwd;"
            
下面，我们讨论一下它们各自的性能。
            
从本质上说，System DSN 和 DSN-less Connection 都是通过 ODBC 与数据库进行连接的，它们之间区别不大(事实上也确实如此)。有很多人说 DSN-less Connection 要优于 System DSN Connection，对这一点我不反对。(是不是前后有些矛盾，刚说它们区别不大，现在又......)我曾经分别对这两种连接测试过，但是失败了。因为我的测试数据没有规律，根本说明不了问题(或许用假设检验能比较两者的性能，不过得算死)。于是我得出了结论：没有结论！后来在网上看到一篇文章 System DSN or DSN-less Connection? 算是有了答案。
            
结论就是(这是原文)：
            
These tests showed that DSN-less connection were slightly faster than System DSN Connections.The increase in performance was nothing monumental(monumental adj.纪念碑的, 纪念物的, 不朽的, 非常的);the greatest performance boost( 推进)was mere 13% faster with 64 concurrent (同时发生的事件adj.并发的, 协作的, 一致的) requests.For one,two,or four concurrent requests,there was virtually no performance improvement.In fact,no noticeable improvement is seen in a DSN-less connection over a System DSN until there are 10 or more concurrent connections.
            
为什么？因为 System DSN 在连接时要读注册表。
            
现在只有OLE DB没有说了(打字真累)。OLE DB 比 ODBC 要高效的多。
            
根本不用测试，这个结论是显而易见的。如果你还有些怀疑，建议去看看 连接池(Connection Pooling)介绍 那里有 MDAC framework 的图示，从图中可以看出，经 ODBC 连接是 ADO-->OLE DB-->ODBC Provider-->ODBC-->driver-->数据库；经 OLE DB 是 ADO-->OLE DB-->DB Provider-->数据库。哪个更直接？当然是 OLE DB!
            
Set cnn = Server.CreateObject("ADODB.Connection")
'Connection string for SQL Server
cnn.Open "Provider=SQLOLEDB;Data Source=srvName;Initial Catalog=DBname;User ID=user_id;Password=yourPassword;"
            
'for Access
cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=db_path"
            
连接数据库就是这么容易！