连接到数据存储

数据

    如果需要访问一个数据存储,应该创建一个到数据存储的连接。前面已经提到过:可以显式地创建一个Connection对象,或者让ADO隐含地创建一个连接。对于任何一种方式,都必须知道数据存储的详细内容。
       虽然用于连接的实际细节不尽相同,但对于所有类型的数据存储,其连接的实际方法是相同的。这并不令人惊奇,因为不同的提供者需要不同类型的信息。在允许用户访问数据存储之前,一些提供者需要用户的证书,而别的提供者却接受默认的安全证书。
       连接到数据源有好几种方法:
       · 连接字符串。在字符串中放入连接的细节,或在打开数据存储时,直接将连接细节加入到命令中。这种方法的优点是连接细节将保留在ASP页面中。不足之处,如果你有较多的页面,在改变了连接细节时,将陷于繁重的维护工作当中。解决的方法是创建一个包含连接细节的字符串变量,并放进一个ASP包含文件,这样的话仅仅有一个连接字符串的实例,但能保持与其他的ASP页面相符。另一个常用的技术就是将应用程序中的连接字符串存储到状态变量中,这样可以被应用程序中的所有页面使用。
       · 数据链接文件。这是一个含有连接细节的文件(扩展名为.udl)。优点是对于任何数据的ASP页面只需要一个数据链接文件。要创建一个数据链接文件,只需创建一个新的文本文件,并重新命名(要确保Windows资源管理器显示文件扩展名)。一旦重新命名了该文件,就可以打开它(双击)以显示Data Link Properties对话框。以前版本的ADO允许从Windows资源管理器的New菜单建立数据链接文件。我们将在本章稍后看到有关数据链接文件的内容。
       · ODBC数据源,或DSN。有点类似于数据链接文件,但只适用于ODBC数据源。它们集中起来用于ASP页面,数据源必须是系统数据源。ODBC数据源从ODBC数据源管理器(ODBC Data Source Administrator)中创建,这个工具可在Administrative Tools文件夹中找到。
       这三种方式无论哪一种都可以使用,使用哪一种只是一种偏爱而已。直接的连接字符串可能速度快一些,因为提供所有的连接细节。数据链接文件需要从文件中读出连接细节,ODBC数据源需要从注册表中读取连接细节。当然,速度的差异是很小的,每种方法各有优缺点。

8.3.1 连接字符串
       连接字符串依赖于提供者,因为每个数据提供者可能需要不同的细节。
       值得注意的重要一点是,ODBC的OLE DB提供者是缺省的,所以,如果不使用Provide=部分,系统将自动地使用ODBC。
       下面为不同的提供者列举了连接字符串的例子,在本书的后面将会看到更多的例子。
1.  微软Access
如果使用ODBC,而没有DSN:
Driver={Microsoft Access Driver (*.mdb)}; DBQ=C:wroxdatabase_name.mdb
对于本地的OLE DB提供者:
Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:wroxdatabase_name.mdb
上面的例子说明了Access数据库存放于C:wrox目录下。虽然读者可能会尝试将数据库作为Web文件存放于相同的目录下,但不要这样做,否则任何人都可以下载整个数据库文件。将数据库存放于Web目录外永远是明智的,没有人可以从外面访问该文件。
2.  微软SQL Server
对于微软SQL Server,使用针对ODBC的提供者:
Driver={SQL Server}; Server=server_name; Database=database_name; UID=user_name;
PWD=user_password
例如:
Driver={SQL Server}; Server=WATCHER; Database=pubs; UID=davids; PWD=whisky
对于本地OLE DB提供者,语法类似:
Provider=SQLOLEDB; Data Source=server_name; Initial Catalog=database_name;
User Id=user_name; Password=user_password
例如:
Provider=SQLOLEDB; Data Source=WATHCHER; Initial Catalog=pubs; User Id=davids;
Password=whisky
3.  微软索引服务
索引服务只能通过本地的OLE DB提供者使用。其语法:
Provider=MSIDXS; Data Source=catalog_name
例如,使用Web目录
Provider=MSIDXS; Data Source=Web
4.  ODBC驱动程序
在使用针对ODBC的OLE DB提供者的例子中,Driver显得较为冗长。例如:
Driver={Microsoft Access Driver (*.mdb)}; DBQ=C:wroxdatabase_name.mdb
当创建一个新数据源时,使用的驱动程序的准确名字应该是从驱动程序列表中得到的,如图8-6所示:

5.  数据链接文件
以前版本的ADO允许在资源管理器中的目录上右击鼠标来创建一个数据链接文件。创建了新文件后,打开该文件从而得到Data Link Properties对话框。在写本书的时候,微软已经从鼠标右键菜单中删除了该选项,因为他们觉得这会让用户感到混乱。但微软声称会提供一个注册表文件以便再次引入这项功能。
不要忘了,也可以简单地通过创建一个空文本文件,并将其扩展名改为.udl来创建一个数据链接文件。
一旦有了物理上的数据链接文件,就可以通过鼠标双击或者右击鼠标选择Open打开文件。接下来,读者会看到图8-7所示的对话框:

图中的详细内容因选择的提供者的不同而不同。上面的例子显示了SQL Server提供者,连接到一个称为WATHER的SQL Server上,以davids的身份登录(口令被屏蔽了),使用pubs数据库。注意,如果选择Allow saving password选择,输入的口令将会在UDL文件中以明文保存下来。
如果要改变提供者,可以选择“Provider”(提供者)选项卡,如图8-8所示:

通过这个选择,可以选出所需的提供者,然后按下Next按钮填入适当的连接细节。
也可以在文本编辑器中编辑文件,如图8-9所示:

可以看到在UDL文件中确实存有一个连接字符串。
要使用数据链接文件,仅需要在打开连接时指定这个数据链接文件:
conPubs.Open "File Name=C:wroxpubs.udl"
6.  ODBC数据源
ODBC数据源(通常称谓数据源名称,即DSN)可以通过Administrative菜单的Data Source选项进行设置。在以前版本的Windows中把它作为控制面板中的一个小程序。为了在ASP页面中访问DSN,必须确定该DSN已经被设置为系统DSN。这只需在Data Source Administrator中选择System DSN选项卡,然后选择Add按钮,如图8-10所示:

然后,就可以选择希望使用的ODBC驱动程序,并填入适当的ODBC参数。
一旦建立了DSN,可以使用连接字符串的“DSN=”属性。例如:
conPubs.Open "DSN=pubs"

8.3.2 使用包含文件
       使用包含文件连接字符串的包含文件提供了一个中心区域来存储许多ASP页面需要的连接细节。要这样做,仅仅需要创建一个新的ASP文件,不妨称为Connection.asp,并在其中加入下面的代码:
       <%
       strConn = "Provider=SQLOLEDB; Data Source=WATCHER; " & _
                     "Initial Catalog=pubs; User Id=davids; Password=whisky"
       %>
       在ASP页面中,现在可以在该页的顶端加入这一行:
       <!-- #INCLUDE FILE="Connection.asp" -->
       这样不必再为每个ASP页面都输入连接细节,同时方便于更改整个站点都使用的连接。       包含文件也是放置METADATA标签的好地方。
8.3.3 使用连接状态
       将连接字符串存入应用程序变量是一个常用的技巧,同使用一个包含文件一样有效。例如,可以在global.asa文件中加入下面的代码:
       Sub Application_OnStart()

              strConn = "Provider=SQLOLEDB; Data Source=WATCHER; " & _
                            "Initial Catalog=pubs; User Id=davids; Password=whisky"
              Set Application("ConnectionString") = strConn

       End Sub
       在ASP页面中,可以使用下面的代码:
       Set conPubs = Server.CreateObject("ADODB.Connection")

       conPubs.Application("ConnectionString")
       从个人的角度,我更喜欢使用包含文件的方法,因为我写了许多不同的连接到各种服务器和数据库的例子。使用应用程序方法将意味着每次必须关闭浏览器重新启动应用程序。读者可以使用自己喜欢的任一种方法,在速度上它们并没有差别。
       对于在本书的这节内的例子,将使用一个含有连接字符串的connection.asp文件人作为一个包含文件。

8.3.4 连接语法
       上面所叙述的是相关理论,当确实要与数据存储连接时,应该怎么办?如果使用显式定义的Connection对象,可以使用Open方法,它的语法如下:
       connection.Open [ConnectionString], [UserID], [Password], [Options]
       参数如表8-1所示:
表8-1  Open方法的参数及说明
参 数
说 明

ConnectionString
包含连接细节的字符串。可以是ODBC DSN的名称、数据链接文件的名称或真实的连接细节

UserID
连接期间,用户使用的名字。覆盖连接字符串中提供的任何用户名

Password
用户的口令。覆盖连接字符串中提供的任何口令

Options
可以是adAsyncConnect,指定异步地建立连接。忽略这个参数,则建立一个同步连接

       异步连接不用于ASP环境,因为脚本语言不能接收来自ADO的事件。

8.3.5 连接的例子
       下面是几个示例,这里假定strConn包含一个有效的连接字符串。
       为了打开一个连接,使用Connection对象的Open方法。例如:
       Set conPubs = Server.Connection("ADODB.Connection")

       conPubs.Open strConn

       ' Some processing

       conPubs.Close
       也可以使用ConnectionString属性:
       Set conPubs = Server.CreateObject("ADODB.Connection")

       conPubs.ConnectionString = strConn
       conPubs.Open

       ' Some processing

       conPubs.Close
       这两种实现方法之间没有什么区别,如果使用前一种方法来实现连接,ConnectionString属性同时也被赋值。
       值得注意的是,一旦与数据存储建立了连接,ADO可能会改变ConnectionString属性值。不必担心,ADO只填写一些额外的属性值。

8.3.6 连接缓冲池
       连接缓冲池(connection pool)总使许多人感到困惑,其实原理非常简单。当关闭一个连接,就用户(和ADO)而言,这个连接已经关闭。但实际上OLE DB并没有关闭这个连接,只是将其放入了非活动的连接缓冲池中。任何时候用户(或其他人)打开一个连接,OLE DB首先检测连接缓冲池中是否有相同连接细节的连接存在。如果有,将直接从缓冲池中取得此连接。如果没有,则为用户创建一个新的连接。为了避免浪费资源,经过一段缺省的时间段后,就从缓冲池中清除该连接。
       那么,它的优点在哪里?打开一个连接可能是所进行的操作中最慢的操作之一,连接缓冲池使用户能与数据存储再次连接而无须重新创建连接。这对于那些连续打开和关闭大量连接的Web站点显得特别重要。
       对于ODBC连接,连接缓冲池由ODBC Data Source Administrator控制。对于OLE DB,不能改变连接缓冲池(或叫会话缓冲池)。
       必须注意的是,连接缓冲池不是连接共享。一个连接只有在被客户关闭后才能再次使用。
       内务处理
       为了使连接缓冲池生效,必须确保内务处理(Housekepping)处于有序状态。这包括及时关闭Connection对象,这样它们才能回到缓冲池重新使用。你可能认为不断地打开、关闭连接对系统的开销很大,但必须衡量一下可扩展性——你的应用程序可能有许多人在使用,OLE DB又非常善于管理连接资源。
       一般的原则是:尽可能晚地建立连接,同时又要尽可能早地关闭连接,这样保证连接打开的时间段最短。

时间: 2024-09-11 10:59:11

连接到数据存储的相关文章

MySQL更改数据库数据存储目录

MySQL数据库默认的数据库文件位于/var/lib/mysql下,有时候由于存储规划等原因,需要更改MySQL数据库的数据存储目录.下文总结整理了实践过程的操作步骤.   1:确认MySQL数据库存储目录 [root@DB-Server tmp]# mysqladmin -u root -p variables | grep datadir   Enter password:   | datadir | /var/lib/mysql/     2:关闭MySQL服务 在更改MySQL的数据目录

数据存储指南之存储备份技术

备份|数据 数据存储备份技术一般包含硬件技术及软件技术等,硬件技术主要是磁带机技术,软件技术主要是通用和专用备份软件技术等. 磁带机技术: 无论是硬盘技术,还是光盘技术,都不适合用来进行数据存储备份,只有磁带机技术才真正适合数据存储备份领域.事实上,磁带机技术长期以来一直是首选的唯一的数据存储备份技术,因为磁带介质不仅能提供高容量.高可靠性以及可管理性,而且价格比光盘.磁盘媒体便宜很多. 作为一种备份设备,磁带机技术也在不断发展.当前市场上的磁带机,按其记录方式来分,可归纳为二大类:一类是数据流

阿里云数据库,破解大型网站架构设计中的数据存储难题

摘要:3月10日,2017阿里云网站行业热点问题和解决方案线下研讨会在上海举行.在本次研讨会上,阿里云数据库团队产品专家王义成(花名挚尤)针对于大型网站的数据库架构设计以及阿里云ApsaraDB所提供的服务管理和解决方案进行了深入介绍. 分享者简介:王义成(花名挚尤),阿里云数据库团队产品专家,负责阿里云NoSQL数据库的产品规划.加入阿里巴巴近5年的时间,参与过多种云数据库的产品设计工作.目前主要负责阿里云的MongoDB.Redis以及MemCache产品,旨在为广大客户提供安全可靠的数据库

Android开发笔记之: 数据存储方式详解_Android

无论是神马平台,神马开发环境,神马软件程序,数据都是核心.对于开发平台来讲,如果对数据的存储有良好的支持,那么对应用程序的开发将会有很大的促进作用.总体的来讲,数据存储方式有三种:一个是文件,一个是数据库,另一个则是网络.其中文件和数据库可能用的稍多一些,文件用起来较为方便,程序可以自己定义格式:数据库用起稍烦锁一些,但它有它的优点,比如在海量数据时性能优越,有查询功能,可以加密,可以加锁,可以跨应用,跨平台等等:网络,则用于比较重要的事情,比如科研,勘探,航空等实时采集到的数据需要马上通过网络

MaxCompute实战之数据存储

MaxCompute(原名ODPS),是阿里巴巴自主研发的海量数据处理平台. 主要服务于批量结构化数据的存储和计算,可以提供海量数据仓库的解决方案以及针对大数据的分析建模服务.支持PB级别数据分析,常用场景如下:大型互联网企业的数据仓库和BI分析.网站的日志分析.电子商务网站的交易分析.用户特征和兴趣挖掘等. 我们接入MaxCompute主要做两个工作,一是网站的日志分析,二是用户特征和兴趣挖掘.其中网站日志分析项目组内(就是高德开放平台)已经玩的比较溜了,"用户特征和兴趣挖掘"还在探

从Facebook看大数据存储怎么选

最近有位朋友向我咨询技术问题,他们的客户提出一个大数据系统的服务器硬件需求,其中元数据有xxTB左右.并给出了以下初步建议: 节点类型1(元数据节点) Xeon E5 14核CPU x2 256GB DDR4内存 600GB SAS 15K硬盘x5 RAID卡 节点类型2(数据节点) Xeon E5 14核CPU x2 128GB DDR4内存 4TB 7.2K近线硬盘x4 RAID卡 软件并非我擅长的方面,不过大数据概念炒了好几年,从各方面还是多少了解到一些Hadoop/HDFS硬件架构方面的

全新版本MongoDB数据存储席卷物联网

本文首先对物联网进行了模型抽象,着重和大家剖析了MongoDB解决方案,包括文档模型.高可用复制集.分片集群和Aggregation&MapReduce,最后分享了全新的MongoDB特性. 以下为内容整理: MongoDB是文档型数据库,其核心的三大优势是灵活文档模型 .高可靠复制集. 高可扩展分片集群.在最新的 DB Engine Rank 的排名中,MongoDB 排在第4,是非关系型数据库领域的领头羊. 物联网模型抽象 物联网离我们越来越近,这主要得益于云计算和移动互联网技术的发展.物联

2017年的数据存储热门技术趋势

2017年已经来临,IT行业人士希望从数据存储技术趋势列表中了解哪些是热门技术,哪些将会没落. 年初岁尾是人们进行总结和预测的时候.在新的一年,人们开始预测数据存储技术的趋势,相信将在新的一年会对存储世界产生巨大的影响.像往年一样,这里没有不切实际的预测,那些日益更新的存储技术被证明是实用的.因此,虽然所提供的存储技术趋势列表是存储行业提供的最好和最全的,但它只包括用户现在可以购买和部署的技术. 以下讨论哪些存储技术将在2017年将产生最深刻的影响. (1)云到云的备份 运行在云计算中的数据并不

Uber是如何使用MySQL设计可扩展性数据存储的?

在Mezzanine项目中我们描述了我们是如何将Uber的核心行程数据从单个的Postgres节点迁移到Schemaless,这是我们开发的一个容错性很高.可用的数据存储. 根据Uber工程师的习惯使用MySQL设计的数据存储,使我们可以从2014 扩容到更高.本文分成三部分对Schemaless进行阐述. 一.Schemaless的总体设计   这一部分我们将讲述Schemaless的架构它在Uber基础结构中的角色以及他是如何成为该角色的. 1.我们对新数据库的迫切需求 2014年初,由于出