查看: 2235|回复: 7

[参考文档] 為什麼「設計」如此重要?

[复制链接]
论坛徽章:
401
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
发表于 2011-4-8 15:20 | 显示全部楼层 |阅读模式
a036_02.pdf (162.38 KB, 下载次数: 42)
论坛徽章:
67
2015年新春福章
日期:2015-03-06 11:57:312012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-01-04 11:49:54ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41鲜花蛋
日期:2011-11-01 08:02:09现任管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-02-18 11:42:472011新春纪念徽章
日期:2011-01-25 15:42:56
发表于 2011-4-8 15:27 | 显示全部楼层

使用道具 举报

回复
论坛徽章:
326
生肖徽章2007版:猴
日期:2008-05-16 11:28:59生肖徽章2007版:马
日期:2008-10-08 17:01:01SQL大赛参与纪念
日期:2011-04-13 12:08:17授权会员
日期:2011-06-17 16:14:53ITPUB元老
日期:2011-06-21 11:47:01ITPUB官方微博粉丝徽章
日期:2011-07-01 09:45:27ITPUB十周年纪念徽章
日期:2011-09-27 16:30:472012新春纪念徽章
日期:2012-01-04 11:51:22海蓝宝石
日期:2012-02-20 19:24:27铁扇公主
日期:2012-02-21 15:03:13
发表于 2011-4-8 15:53 | 显示全部楼层
〇 〇 〇 〇 〇 〇 〇 yeah。。。。。。

使用道具 举报

回复
求职 : 数据库开发
认证徽章
论坛徽章:
28
ITPUB学员
日期:2009-10-14 18:49:45至尊黑钻
日期:2015-12-31 11:11:56数据库板块每日发贴之星
日期:2009-10-22 01:01:02优秀写手
日期:2014-04-30 06:00:17ITPUB8周年纪念徽章
日期:2009-10-09 21:30:10马上有车
日期:2014-10-09 10:14:53马上有钱
日期:2014-02-18 16:43:09路虎
日期:2013-10-15 15:38:59林肯
日期:2013-09-12 15:57:33ITPUB 11周年纪念徽章
日期:2012-10-09 18:11:48
发表于 2011-4-8 15:55 | 显示全部楼层
oracle 7的,总觉得翻译的很糟糕啊。。“唯读的tablespace”.“呼叫SQL”.这是专业术语吗??

使用道具 举报

回复
论坛徽章:
401
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
 楼主| 发表于 2011-4-8 16:03 | 显示全部楼层
对岸的术语,看懂就行

使用道具 举报

回复
论坛徽章:
7
2011新春纪念徽章
日期:2011-02-18 11:43:342010广州亚运会纪念徽章:羽毛球
日期:2011-03-31 09:40:352010广州亚运会纪念徽章:卡巴迪
日期:2011-04-26 13:46:28ITPUB十周年纪念徽章
日期:2011-11-01 16:26:292012新春纪念徽章
日期:2012-01-04 11:57:36ITPUB 11周年纪念徽章
日期:2012-10-09 18:16:00优秀写手
日期:2013-12-18 09:29:11
发表于 2011-4-8 16:37 | 显示全部楼层
良好的设计保持产品的稳定性。
所谓勿以善小而不为,作为开发人员,大多数都烦设计,来了需求,听完需求分析后就立马搞起代码,
很少去想这个功能模块是否会牵涉以前的一些旧模块,我的对象的引入对以前有什么影响或者我修改了旧对象是否提高旧对象设计的不完整性和冗余,总之要么就加个新对象,加一个新索引,在以前过程后面加个dml操作,反正只要实现本次功能,不影响旧功能就行了。
随着时间的流逝,模块越来越多,而我们的代码冗余也越来越大,许多问题就会慢慢浮出水面,接下来的任务就是不断的救火,不断的填补漏洞。
我们不能保证我们做了详细的设计后后面就不会出现问题,但是我们有理由相信我们认真对待设计这个问题时,后面会不断减少救火的情况。

使用道具 举报

回复
论坛徽章:
7
咸鸭蛋
日期:2011-06-30 12:39:29ITPUB十周年纪念徽章
日期:2011-11-01 16:24:512012新春纪念徽章
日期:2012-01-04 11:54:46咸鸭蛋
日期:2012-06-12 16:27:26马上有对象
日期:2014-04-28 20:10:27乌索普
日期:2018-03-15 13:56:21技术图书徽章
日期:2018-03-19 18:10:41
发表于 2011-4-8 21:59 | 显示全部楼层
我们最常见的就是X用户说要一个界面,要数据ABCD
然后Y用户说要一个报表,统计ABCD数据
然后XY用户最后算出来不一致打架,最后得出结论,你们的软件不好用 =.='

使用道具 举报

回复
论坛徽章:
401
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
 楼主| 发表于 2011-4-9 21:34 | 显示全部楼层
本章内容:第二章
*针对特定架构作设计
*为系统效能而设计
*其它设计上的考虑
*针对Oracle7设计
*Oracle8简介为什么「设计」
如此重要?
本章将介绍对Oracle数据库而言,设计完备的重要性。之所以不同其它关连式资
料库,在于Oracle支持多种不同架构及操作环境。同样的应用程序可以在单机的
个人计算机上使用,也可以在上千人使用的大型主机上运作,影响效能最重要的因素
当然就是设计的好坏了。Oracle还提供许多功能,可以使用不同的方法和机制来达
成同样目标。身为设计师,必须在现有主客观的环境下,选择最恰当的设计和作
法。
在这一章将介绍Oracle支持的重要架构;包括主从式(client/server)、分布式数据
库(distributeddatabase)、数据仓储(datawarehousing)、以及平行处理(parallel
processing)。相关主题将在本书的第三部份深入讨索。我们也将勾勒出系统效能最
佳化的轮廓。最后,会扼要列出对设计师来说Oracle7相当重要的特性,并介绍
Oracle8即将引进的新功能。
35

36/第二章
针对特定的架构来作设计
有时候,目标系统架构会被主客观环境所局限;例如,公司?,每个人都使用个人
计算机的情况下,可说除了主从式架构外,几乎没有其它选择。通常在分析阶段产生
的限制(constraints),左右着我们对于相关作法的选择;产能(throughput)可能
是某个系统的主要诉求,而效能评估(benchmark)则透露出我们必须使用Oracle
的ParallelQueryOption才能达到要求。不管是什么原因,都该好好考虑其它选
择。有些人倾向使用较先进的技术(这样比较有趣,因为履历表上可增添比较炫丽
的纪录),但我们应当回过头来好好考虑现实情况,充分了解使用不同技术将会带
来什么样的结果。
让我们看看会影响设计的特定架构。
主从式架构
所谓主从式架构,就是客户端(client)通常与数据库服务器(server)分离的电
脑。客户端与服务器可能透过高频宽的局域网络(LocalAreaNetwork,简称
LAN),也可能是透过广域网络(WideAreaNetwork,简称WAN)(相对地,频宽
较低,速度较慢)的连结。
要建置好的主从式架构的关键,在于有效地分离客户端及服务器两边的程序运作,
像是讯息传送至两端的往返时间(roundtriptime,又称为messagepairs)降低。
其次,是要将传送的讯息长度减至最短。假使能够遵循这两个原则,会发现客户端
及服务器的状态都保持在颠峰。客户端以友善的接口引导使用者完成工作,服务器
则保证数据的整合性,以最快速度响应客户端的要求。
在设计程序(procedure)时,必须考虑将它放在客户端、服务器还是两边都要。某
些特殊情况,最好分开在客户端及服务器;而某些情况,最好是两边都复制一份。
不过,大致说来,应把使用者接口管理摆在客户端(前端),而数据逻辑处理摆在
服务器端(后端)。位置的误放往往会严重影响系统效能及使用率。
如果以三层式(three-tier)架构考虑,则期望能将接口逻辑(presentationlogic)
放在客户端,程序逻辑(applicationlogic)置于中间层,而数据逻辑(datalogic)
则位在数据服务器。Oracle网络运算架构(NetworkComputingArchitecture,简称
NCA),让three-tier、甚至n-tier架构的应用程序更易作到。(如需更多这方面的
信息,请详阅后头讨论「Version7.3」NCA的章节)

为什么「设计」如此重要?/37
让我们再回头看看租车公司的例子。该公司将在PC上执行主从式架构的应用软
体。对于使用者,最重要的是能快速处理归还的车子,因为客户通常在赶时间(比
方说赶飞机)。因此,我们决定将还车的程序设计成:输入租车号码时,会将该交
易所需的数据从服务器端下载,然后储存在客户端。这些数据不需要一次显示到萤
幕上,但是会被储存在客户端PC的内存或磁盘驱动器。当交易完成时,只需将更动
的部份传回服务器。从Oracle角度,我们需要一打的预储程序处理,客户端的要
求,而客户端不会直接参考服务器中的Oracle表格。
这部分在第十一章会有更详细的讨论。
分布式数据库
分布式数据库(distributeddatabase)会将数据管理及相关数据,储存在一个以上
的服务器上。设计分布式数据库最重要的课题,就是在不同的服务器间,找到分散
数据最佳化的方法。数据分散的好处,在于能将数据置于较接近主要使用者,提升
执行效率,并且降低对单一服务器的依赖。有很多可行的技术可供选择。
有些数据很难分割(partition),唯一的解决方式就是将这些数据摆在同一台服务器
上。有些数据可能天生就适合被放置在不同服务器上,比如说,依照地理位置分布
的数据(像是国家或区域性的数据就可放在该区域的服务器中)。分割过的数据可
以从远程利用分布式查询取得,甚至可以透过多点同时更新的方式进行数据更新。
另外一种分割数据的作法,是将其它服务器上备份的数据设定成只读,而这些备份
称之为快照(snapshot)。虽然它会定时更新,但并不保证每次的资料都是最新的。
对于不需要在特定服务器上储存的数据,可以使用名为multi-master的技术解决。
这项技术允许各个服务器拥有同样表格,就像任何本地的数据可以随时更新。表格
的变更需要同步(也就是确认更新数据时,所有服务器的复本也能同时更新),或
异步(过一段时间再执行更新程序)更新其它副本。
Oracle利用SQL*Net支持数据库连结(databaselink)、二段式委任(two-phase
commits)、snapshot、read-onlysnapshot、及复制等功能。

38/第二章
在我们的例子中,决定在每个较大的地点(如主要的机场)配置一台服务器。当地
的数据库储存预备出租车子的细节。一旦车子出租时,车子资料及租约会马上传到
中央的服务器(因为我们不知道车子会在哪里被归还)。所有的账面(billing)资
料都来自中央服务器,但是考虑到效能,我们还是在当地的计算机中,复制一份只读
的资料。当地的税务信息则存放于当地的服务器中。我们将基于Read-only
Snapshot(如价格及一些参考数据)和异步复制(车子的数据库)的原则,设计
分布式纲要(schema)。这样的设计是,当中央服务器挂掉时,各地的租车地点不
会受影响。
关于这部分,在第十二章会有更详细的介绍。
资料仓储
有些应用软件需要处理复杂的管理报表,但在第一章租车公司的Moscow分析中,
曾提及管理报表必定不属于项目的内容。为什么呢?原因如下:
无法预期所有使用者想要的报表,即使身为决策者也面临同样问题。决策
是抽象且重复的领域,看完报表后,常会让人更想看到另外一种报表。
营运数据库(operationaldatabase),通常是针对交易型态的运作作最佳
化。复杂的报表通常需要利用不同表格完成,而且会大大降低整个系统的
运作效能。
数据仓储的概念是从营运系统中撷取数据,转换成更适合复杂查询的格式,并且储
存于可容纳大量成长、且不须存在于现行系统的历史数据数据库中。在此数据库
中,增加一种特别的查询工具,让使用者能够自由查询所需的信息。这样的数据库
跟传统的在线交易处理(onlinetransactionprocessing,简称OLTP)相当不同,有
许多像是维度分析(dimensionalanalysis)的新技术需要学习。
在我们的例子,公司管理阶层想要进一步了解租车市场整体变化及趋势。有时,某
地会在忙碌的工作天中,将某款的车子全部出租;甚至会出租所有的车子!因此,
公司能有效掌握供需、并且事先做好调度,是非常重要。
细节留待第十三章,再做进一步的讨论。

为什么「设计」如此重要?/39
平行处理
平行处理的精神,在于尽可能的使用所有硬件资源(像是CPU及储存装置,特别
是磁盘驱动器)。Oracle为了支持多CPU的机器,也提供一些特别设计。使用Parallel
QueryOption,可以把某些查询分成不同部份,再将每部份送交不同的CPU处理。
同样地,平行处理的技巧也可以应用于磁盘驱动器上,将读写的动作划分于不同磁盘驱动器
上。此时,我们必须确实知道系统的瓶颈在哪?,像是「产能及服务器负荷,会不
会比网络限制还大」的这类问题。
即使没打算使用平行处理功能,仍可遵循一些标准和基本规则。让我们看看租车公
司的例子。
租车系统所使用的平台(Platform),是配置四颗CPU及128MB内存的Unix伺
服器。每个月结帐时,服务器上不会有其它任何的活动。所以,在正常情况下,其
它三颗CPU几乎都处于闲置状态。因此,决定藉由分割待处理数据,交由不同的
CPU同步处理,以增加系统产能。当然,必须确定是不会相互影响,不然,这个
聪明小技巧就会失灵了。
我们还打算使用RAID1技术,提供单一硬盘毁损时的回复动作,避免因损坏造成
财务损失,这样还能带来同步读写的好处。
要知道更详细的平行处理技巧,请参阅第十三章。
为系统效能而设计
确保系统具备足够效能,是数据库设计的主要目标之一。一般来说,设计不良的
Oracle数据库执行效能很差,而且无法藉由更新硬件的方法来改善。修正设计不良
的系统,所需的代价就是重新设计,也就是将旧有设计完全抛除,重新开始。使用
者越来越无法忍受缓慢的反应时间,完全是由于PC软件发达,硬设备不断改
进,人们认为系统效能也应增加才是。
Oracle注意到对高效能的需求,以及硬件技术不断进步,因此,设计Oracle
ParallelServer,以便在大量的平行处理系统发挥功效。在这种架构下,有些益处
是不容置疑,其它仍须小心的设计。

40/第二章
如果没有修好错误设计,系统将会付出极大代价,因为使用者会认为这套系统非常
差劲。许多使用者会对系统持疑,是因为以前就是使用相当差的系统。
几乎所有的设计层面都会对系统效能造成影响,在接下来的章节中,我们将讨论一
些较关键的因素。
Key和索引
我们必须小心选择表格的key以及索引(Index),将应用软件用到的数据列入考
量。此外,必须检视所有的模块,询问使用者较常查询那些类型的数据。我们必须
在查询(query)和新增(insert)/修改(update),取得很好的平衡点-因
为,表格加入的索引越多,当新增、更新、甚至删除纪录时,Oracle要作的事(维
护资料)就越多。所以,在执行包含许多新增、修改、或删除的批次作业时,应先
考虑除去一些索引。
在某些情形下,数据的放置位置对系统效能有相当大的影响。也许我们应当考虑将
数据丛集于key值的附近,具有相同key值的数据自然地就会很接近。另外,常藉
由特殊的uniquekey存取静态表格时,我们可能会使用一个hashcluster。
在我们的例子,我不认为有合适的丛集,不过,仍希望藉由在表格中增加额外的索
引,提升查询速度。举例来说,我们在RENTAL_CARS表格(RENTAL_CARS的主键
是CAR_ID)的REGISTRATION_NUMBER字段上,建立索引,如此一来,当我们想
用uniquekey找寻车子的时候,便可很快找到。
第六章会对key以及索引有更深入的探讨。
反正规化
反正规化(denormalization),是如何在数据库中选择重复储存数据的一门艺术。
假如信息可以从其它地方衍生而来,就称为redundant(重复)。到目前为止,最
常见的是在父纪录上记录子纪录的总和等数据,就不需要重新计算所有的子纪录。
至于,在key的选择上,反正规化的诉求是:在加快查询及降低数据维护速度上取
得平衡。

为什么「设计」如此重要?/41
有时候,除了反正规化外,还有其它的选择方案。假使报表必须全面的反正规化才
能改善速度,可以先将相关的数据,事先拷贝到暂时的表格?,就可以很快的产生
报表了。
范例中,我们在CUSTOMERS表格中增加OUTSTANDING_INVOICE_AMOUNT栏
位,代表顾客在INVOICES表格中,所有STATUS不是PAID的INVOICES_AMOUNT
的总和。因此,查阅顾客所有的发票,便能很快作信用查询。我们在INVOICES上建
立触发程序(trigger)来维护这个值。比如说,当STATUS更新为PAID时,
CUSTOMERS表格中属于该客户的OUTSTANDING_INVOICE_AMOUNT,便会自动扣
除INVOICE_AMOUNT。
第四章会更详细介绍反正规化的观念。

选择最佳化处理器
Oracle7提供两个最佳化处理器(optimizer),提供SQL查询最佳化不同的取向。
以往rules-based取向使用一系列规则,决定该采用什么样的存取路径(access
path),而cost-based则试图使用较聪明的方法:数据库大小及数据分散程度透过
它作决定。
也许,你会认为应能在这两种模式之间自由的切换,而不需要担心系统如何设计。
但事实上,仍须选择其中一个作为设计的基础,因为你已经知道哪一个才是最佳化
的路径,此时要能引导系统走向这个路径。
因为租车系统是全新的系统,不需采用旧程序,所以我们选择使用cost-based取
向。如果系统?数据的分布改变很多时,我们所选择的optimizer应该会自动的跟
着改变。
第六章将会有更详细的讨论。
程序设计技巧
先前提到系统效能技巧,大部份集中在数据库,但是我们还要看看设计程序时,需
要注意什么。在讨论主从式架构的时候,已经稍稍提过。比如说,我们会把共通及
经常存取数据库的程序,放在预储套件(storedpackage)及程序(procedure)
中。还决定把不常变动的数据放在本地的cache以加快速度。

42/第二章
也许还可以考虑如何减少客户端及服务器端间呼叫的次数。比方说,大部份Oracle
提供的工具能让你使用数组接口(arrayinterface),在单一查询(或其它修改、删
除等)中处理整个数组的数据域位。
其它设计上的考虑
这一节将讨论,在决定数据库设计上作时,需要考虑到关连式数据库的其它特性。
超大型数据库(简称VLDB)
现今大部份的数据库都要处理数亿或数兆的数据。数据逐年增长,但不该对系统产
生严重影响。数据库及数据本身必须能随时被适当管理及控制。不管是多有经验的
DBA,都无法弥补设计不良,无法处理高数据容量的数据库。
幸运的是,Oracle可以处理庞大的数据库,而不会对系统有显著影响。设计师在此
扮演的角色,是要能决定数据对象的适当大小,以及决定最适切数据可能增长的空
间,使得数据增长不会造成问题。
与时间序列有关的资料
因为关连式数据库将数据储存在表格中,因此数据本身就具有二维的本质。当你试
着想加入更多的维数时(也就是变成多维的数据),就得作调整。如果没有适当的
调整,系统就不会产生预期结果,或是需要很长时间才能得到正确结果。最糟的
是,甚至花好长时间却换来错误结果。
最常需要增加的维度就是时间。我们常常需要在更新一个字段时,将旧数据记录下
来,以保有该笔纪录的完整历史(history)资料。这样我们就能够使用过去数据,
查核或是执行交易(比如说,以上个月的价格开列账单),特别是在表格中加入像
DATE_TO及DATE_FROM的字段。不要被这看似简单的作法所欺骗了,蕴含许多
复杂的机制,在第七章会有更详细的讨论。
在租车例子中,我们在BILLING_RATES表格中增加一对字段(DATE_TO、
DATE_FROM),可以在需要的时候重新计算过去的账单。

为什么「设计」如此重要?/43
与其它系统连结
不幸的是,少有项目是从头开始,也就是说,接项目的时候,需要处理旧系统遗留
的资料。这些数据有可能是参考用的,也有可能是交易数据,或者两者都是。同样
地,计算机系统也不是一个与外界隔绝的世界?,通常都需要与其它外部系统作数据
交换。
数据交换有许多方法。使用档案交换数据到现在仍很普遍;提供数据的系统将数据
储存到固定格式的档案上,传送到接收数据的系统中,接收端再使用应用程序读取
并更新数据。但对现今的数据库,就不用这么麻烦了。透过某个接口直接读取资
料,再写到另一个系统上。但是,每个接口都需要仔细的评估,决定该数据应以何
种方式传送。当然,前提是接收端是否需要实时的数据。如果我们将数据在夜间传
送过去的话,就代表该数据是过期(二十四小时)的了,对于变动性的数据,这种
做法是不能被接受的。
在第八章将更进一步地探讨这个问题。
现在,让我们再回头看看租车的例子。旧系统留下具固定长度、旧系统产生的最简
单元格式的资料。当新系统上线时,会有一组和会计系统连结的中介表格。我们会设
计「快速还车」的功能,方便行程较匆忙的客户快速还车。只要在租赁契约?多填
一点数据,就可以完成还车手续。而我们只需使用条形码机及OCR(光学辨识系统)
将数据存入档案,并于夜间将数据加载系统中。
针对Oracle7设计
如同先前提到的,设计是为了能够使用所有的资源及技术。当你特别针对Oracle设
计时,会发现不同版本会对系统设计决策产生重大影响,因为越新的版本拥有越多
的功能。
本书假设你在Oracle有相当程度的经验。所以,这个章节不会试图完整描述
Oracle,仅是简单介绍会对系统有重大影响的功能,以及为何如此重要。

44/第二章
注意如果你对Oracle7相当了解,你可以跳过这个章节,不过请
先确定你已经很熟悉底下的名词。
触发程序及预储程序
Sharedpool
Bufferpool
宣告式限制(Declarativeconstraints)
只读(Read-only)tablespaces
对称式复制(Symmetricreplication)
手动分割(Manualpartitioning)
须注意,现今有许多Oracle客户,同时在不同服务器上使用Oracle不同版本,要
他们使用一致的版本是相当困难。也就是说,在任何时刻,不同地方,会有不同的
版本运作着,甚至同一台服务器上也可能有不同的版本共存。有许多原因造成这样
的结果,所以,最简单、也最常见的方法就是,当客户要使用新版本前,须先经过
测试。
更复杂的情况是该客户拥有多种不同的平台,而Oracle对于各个平台版本发行的
时间并不一致。事实上,还有一些平台从未出现某些版本。
Oracle最大的特色,就是旧版本能与新版本兼容。Oracle花了相当时间确定新版本
能与旧版本兼容。兼容的问题通常出现在Oracle5与Oracle6之间。对大多数读
者来说,这已经是历史事件了。虽然外头仍有某些地方还在使用Oracle5,像我们
知道在一九九六年六月时,在欧洲仍有许多的Oracle5,原因是仍能达到运行效能
的需求,因此没有理由改版。
不过须注意,当新的版本有任何改变时,比如说在SQL语言中增加一个保留字,
你会有两种选择:一是执行兼容模式(使一些新的功能失效),或者确定该保留字
并未出现任何对象或字段名称中。

为什么「设计」如此重要?/45
在底下的例子,我们不考虑软件授权的问题(虽然有许多功能是要多付点钱才有
的),而且Oracle付费规定会改变,因此建议在使用某些功能之前,能够事先检查
自己的版本有没有授权该项功能。
版本7.0
这一节将会简要提及Oracle7,对设计造成重大影响的关键功能。
触发程序、程序、以及函式
原始的Oracle7版本中,导入能在数据库引擎中、储存并执行程序代码的概念。触发
程序(trigger)是位于后端的程序代码,可用来处理表格,而程序(procedure)及函
式(function)则可以由客户端的应用程序透过PL/SQL来呼叫执行。
PL/SQL是Oracle专有的可携式3GL【译注:可以在不同平台的Oracle上执行】。
PL/SQL在Oracle6到Oracle7之间加入许多功能,但能做的事仍很有限。虽说
PL/SQL的一些功能很吸引人,可以有效建构数据规则和企业法则,但是缺少开发
一套完整应用程序的强大功能及弹性。
从架构来看,PL/SQL引擎是独立于SQL引擎,其它如OracleForm及Oracle
Report,也可以使用PL/SQL。
Oracle7数据库设计的关键要素,就是能有效分配前端及后端该做的事。
Cost-basedoptimizer
Oracle7还导入Oracle的cost-basedoptimizer(在前章有提到,以成本为基础的最
佳化处理器),及新的SQL指令ANALYZE来取得统计数据。虽然新的optimizer
带来一些好处,但是却没有达到许多客户的需求,因此他们仍继续使用旧的rules-
basedoptimizer。这一版的optimizer没能将key值的分布状况考虑进去,并且没有
执行查询的成本模型(costmodel)。

46/第二章
Cost-basedoptimizer最大的特色,就是允许程序设计师提供optimizer提示(hint)
来执行查询,不像前版Oracle使用暧昧的方法。即使有适当的索引,还要扫描整
个数据库的数据(fulltablescan)时,传统的作法是:
SELECTe.employee_name
FROMemployeese
WHERENVL(e.division,NULL)='SALES'.
而cost-basedoptimizer则使用更合理的方式达到同样的效果:
SELECT/*+FULLE*/e.employee_name
FROMemployeese
WHEREe.division='SALES'.
第二种作法在效率上有显著的好处,因为它不会执行多余的函式(此例为NVL)。
并不是SQL函式特别没有效率,只因它是直译式语言,因此应该避免执行多余的
函式。
注意附带一提,大部份的书及Oracle课程都建议使用字符串连结或
加法来避免使用索引。比如说:
WHEREe.division||''='SALES'

WHEREe.deptno+0=30
但是,在我们所测试过的Oracle版本中,都发现NVL函式比
字符串连结或加法,都要快的多。
能够控制查询的最佳化,对设计师来说是一大福音。有时设计师必须避开某种程序
结构,以免系统效能变差,控制最佳化就可以少了这层顾虑。但如同先前提到,要
想得到这个好处,必须等到Oracle7.3以后,才能够使Optimizer考虑数据分布的
情形。
Oracle7对于分布式join的最佳化有相当的改变,也解决一些重大的系统效能问
题。

为什么「设计」如此重要?/47
宣告性限制
除了能在表格中定义触发程序外,以及之前NOTNULL的限制外,Oracle7还增加
宣告性限制(declarativeconstraint)。虽然Oracle6中已经支持这个延伸功能,但
并没有实际强制执行。令技术人员惊讶的是,自从Oracle7引入这个功能后,数据
库设计师和DBA却不愿意使用。
使用宣告性限制将对系统设计有重大影响,特别是用FOREIGNKEY的constraint,
将会影响设计查询或参考的表格。虽然宣告性限制对数据整合重要贡献,它们却是
在命令层次(commandlevel)、而非交易层次(transactionlevel)执行,发生所谓
的「暂时性的冲突」(interimviolation)。
分布式数据库
Oracle7还增加两段式委任(two-phasecommit,简称2PC,用来确保正确更新及
删除数据),以便SQL*Net的DML(INSERT、UPDATE、DELETE、LOCK、SELECT
FORUPDATE)支持分布式数据库的运作。这么做相当有用,但却因为许多理由不
常被使用,我们会在第十二章讨论这些问题。各地对分布式系统网络拓蹼结构,及
分布式资料分布的研究,对Oracle是一个崭新的研究方向。
在这个版本,首次导入新的数据库对象-快照(snapshot),可以将地点已改变
的数据定时传送到其它地点,对系统造成一定程度的负面影响,我们将在稍后的版
本中提到。
服务器的效能
Oracle7还提到解决6.0版的系统效能,并对SQL引擎管理高速缓存的方法作了
重大改变。
对SQL,Oracle总是使用动态、非静态的配置。也就是说,SQL指令的执行计划
(executionplan)是在执行时(runtime)才被决定,而不是在准备(preparation)
阶段。因此,每执行一个SQL指令,数据库引擎总是会先决定该指令应该在那?
执行达到及最佳化。

48/第二章
7.0版引进一个新的概念-sharedpool。使用者能够使用其它人建立的执行计
画。如在客户端的程序执行一连串的步骤,则可完全感受这个功能所带来的好处。
从主从式的架构来看,Oracle较早期的版本总是传送太多的网络交换讯息,因此
7.0版正式导入复合式呼叫(compoundcalls)。这个功能将在第十一章有详细讨
论。
其它重要的功能
许多Oracle7新的功能,我们将探讨两个对系统设计产生重大影响的功能。
第一个是支持binarylongobjects(BLOB),能在单一字段中储存超过2GB的资

料。BLOB让我们能储存像是图形或是文字处理的档案,而不需将这类数据分散到
多个字段。虽然,7.0版只可读取一小部份的数据,但是整个BLOB仍需一次完成
新增(insert)的程序,因此,实际上仍有大约1MB的长度限制。在整个资料空
间管理例行程序(routine)无法最佳化处理BLOB的情况下,未来可能会有效率的
问题。
第二个改进的地方则是在系统安全方面,增加「角色」(role)以及profile。这么
一来,对系统要求不高的应用程序,安全控管子系统的设计会较容易,问题也较
少。与数据有关的安全问题(比如说,某个使用者只能够看到某些单位的薪资),
则仍属于应用程序设计的范畴。
版本7.1
基于Oracle7,7.1则增加许多与设计师及管理者取向的功能,对系统设计都有高度
的影响。
PL/SQL中的动态SQL
7.0版可以用PL/SQL预储程序(storedPL/SQLprocedure),包装应用程序的功
能,也就是客户端只需启动单一的程序,而不需要执行所有SQL命令,就可达到
同样的功能。更新变得相当简单,但查询就变得很没效率,无可避免的,客户端必
须指定选择的限制(selectioncriteria)。PL/SQL程序包含一组相当大、且需要执行

为什么「设计」如此重要?/49
的SQL查询指令,为了要解决这个问题,Oracle7.1可以让storedPL/SQL
procedure执行真正的动态SQL。程序可以自行在VARCHAR中建立自己的SQL指
令并执行之。
这样的作法,无疑是搭起前端应用程序和后端数据库之间友谊的桥梁。喔...不,是
中介层(middlelayer),免除应用程序对数据库结构的相依(dependency),也更容
易地移植到其它的DBMS上。
多重触发程序
为了应付复杂的确认及各个程序之间的交错讯息,我们会使用越来越多表格层次
(table-level)的触发程序。但是这样很可能会导致,使用者增加手稿(script)时
的失败,因为新增的触发程序可能与已存在的触发程序发生冲突。7.1版为了要解
决这个问题,允许一个事件可以有许多同时发生的触发程序。可以保证在同样的表
格上,所有触发程序会各自将数据改变的讯息传送出去。
这项功能的主要理念,是要将个别的商业或数据确认规则,对应到个别的触发程
序,而不要将许多不相关的规则合并到单一的触发程序中。
SQL中的PL/SQL函式
如同先前提到的,PL/SQL引擎是自外于SQL引擎的。在7.1版中,可以在SQL
当中呼叫PL/SQL函式。举例来说:
CREATEORREPLACEFUNCTIONcube(xINNUMBER)
RETURNNUMBERIS
BEGIN
RETURNx**3;
END;
可以扩充成SQL语言查询的型态:
SELECTe.emp_name
,e.basic
,t.gross
FROMemployeee

50/第二章
,emp_year_totalst
WHEREe.emp#=t.emp#
ANDt.year=1995
ANDt.gross>=CUBE(e.basic)
ORDERBYt.gross/e.basicDESC;
这会造成一些潜在问题,因为PL/SQL有永久性套件变量(persistentpackage
variable),发出DML命令。Oracle提供宣告PL/SQL函式的puritylevel的功能,
puritylevel可用来控制可能造成的后果,比如说改变数据库结构。
如果你要在SQL中使用PL/SQL,那就应该在数据库设计时期就作好测试。我们
建议不要在SQL指令中使用PL/SQL,除非它们确实是专门设计用来呼叫SQL
的。
只读的tablespace
Oracle在数据文件的开头,都会有一个用来告知数据库,在合法启动时,哪一个是
必须使用、且最旧的redolog的标头区(headerblock)。7.1版以前,这个意思
是:不管数据是否曾被更改过,所有的数据都必须定时的备份,不然,在系统回复
(recovery)时,Oracle会坚持从最旧的log档案开始处理。
为了减少备份及缩短回复时间,7.1版本提供能设定tablespace为只读(readonly)
状态的功能。一旦将tablespace备份后,就不需要再重新备份,因为回复的程序知
道该数据在备份后不可能被更改,也就不去处理这个档案。对大型的数据表格而
言,这种作法相当理想,而且也减少将近百分之九十的备份容量。缺点则是要将资
料设定成只读时,可能需要将数据分割(partition)才能够达成。
在设计实体数据库的位置时,可能希望区分出易变或不易变动的资料,而将较不易
变动的资料放置于只读的Tablespace中。当你和DBA一起规划备份计划时,别忘
了考虑此放置地点。

为什么「设计」如此重要?/51
PQO
Oracle具有合理的可扩展性架构。除了系统本身需要处理的读写工作外,使用者都
有单独的Oracleserver进程。可以在对称式多处理器(symmetric
multiprocessing,简称SMP)环境下,分配到所有可使用的CPU上。但是,对执
行一个既大且复杂的SQL查询进程,就没有太多效果。在7.1版中,平行查询选
项(parallelqueryoption,简称PQO)就可以将单一的fulltablescan查询,分布
在各个CPU上执行。PQO的功能可以查询任何型态的fulltablescan,达到CPU
及磁盘读写动作百分之百的使用率。
当你在设计批次进程及复杂的报表时,应该要检视哪些模块可以使用这项功能,并
且决定最适合该平台数目的进程。还需要与DBA讨论,如何将表格拆开,分散到
不同的磁盘上。
PQO对索引建立的时间,具有戏剧性的影响。
在第十四章,我们会针对这个功能做进一步的介绍。
版本7.1.6
版本7.1.6导入了一些对于系统设计会有影响的功能。
对称式复制
7.1.6版支持Oracle的对称式复制(symmetricreplication),也就是允许同样数据
的备份可以在不同地点独立更新,并且以异步的方式,将变动的数据传到其它备
份上,具有侦测冲突数据及解决的功能。
在分布式的环境中,我们必须要确定哪个复本执行了命令,所以Oracle建立了一
套RepCat(replicationcatalogue)程序,用来维护分散在各个不同复本的数据字
典(datadictionary)物件。
数据改变的传送方式,是使用异步的RPC(remoteprocedurecall,远程程序呼
叫)。利用二段式委任来确定,数据在不同备份上的完整性。这个功能也可用在资
料库服务器中,执行PL/SQL使用者应用程序代码。

52/第二章
第十二章详细介绍在使用异步更新设计时,需要考虑的问题。希望你能知道非同
步的运作不能是一个查询:原因在于它没有办法回答原呼叫者任何查询的结果,已
继续完成其它工作。
Sharedpool
较早的Oracle7版本面临管理sharedpool的问题。对于这些问题的深入研究并不
在本书讨论的范围内,而是在触发程序被放在高速缓存的方式,及pool会越来
越零碎的情形。
先前也提过,触发程序最主要的功能,就是在数据被更动时,执行辅助动作。大概
也可以猜想,Oracle对称式复制功能将使用许多触发程序,而它可能对sharedpool
所造成的影响,在这个版本也作了处理。
版本7.2
这一节将讨论7.2对系统设计的重大影响。
手动分割
版本7.2新增了手动分割(manualpartitioning)数据分割方式。简单地说,7.2版
的查询最佳化处理器,在某些限制下,可以延迟执行join的动作到UNIONALL
型态的视界(view)下。
假设有两个表格(ORDERS及OLD_ORDERS),有着一样的字段及索引,而我们
定义一个叫ALL_ORDERS的视界如下:
SELECT*fromORDERS
UNIONALL
SELECT*fromOLD_OLDERS;
查询为:
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,all_orderso
WHEREc.zip=12345ANDc.cust#=o.cust#;

为什么「设计」如此重要?/53
将会用以下方式执行:
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,orderso
WHEREc.zip=12345ANDc.cust#=o.cust#
UNIONALL
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,old_orderso
WHEREc.zip=12345ANDc.cust#=o.cust#;
在早期的版本,这个视界在join之前就被初始化。视界的初始化需要先建立暂时
的表格,执行建立这个视界所需的join和运算。但是,对大型表格中执行高选择
性的查询,会产生很糟的效能。
这个功能对设计多维表格(比如,时间性(temporal)或空间性(spatial)的数据)
时,有特别重要的影响,因为它们经常使用「手动分割」这种技巧。这个技巧对设
计存盘(archive)资料策略也特别有用,因为经常需要同时处理存盘及目前资料。
PL/SQLscheduler
7.2版中包含PL/SQLscheduler(排程器),允许使用者或开发人员设定定时启动的
PL/SQL工作。这可以解决Oracle7子系统缺少定时处理批次作业的问题。
不需等待响应的程序呼叫接口(Nonblockingcall)
另一个设计师最想要的功能,便是不需任何响应,就可以让Oracle工作。在7.2
中,是以nonblockingcall的方式,出现在OracleCallInterface(OCI)中,也是
C/C++最常使用的接口。
多年前,当Oracle推出第一版的precompiler时,可以将SQL呼叫码直接写在C
及COBOL这类3GL中。当时,Oracle就宣称想要放弃支持OCI的意图。由于许
多技术上的因素,这个想法遭到开发Oracle软件的厂商强力反对,最重要的理由
是OCI可以让函式将数据库的cursor(指针),以参数的型态传给另一个函式,这

54/第二章
样就可以设计通用的函式,处理任何cursor。7.0版的Oracle更改一些内部结构,
OCI便有了最新的功能。尔后,7.2版又增加nonblockingcall的功能,这意谓着又
多一个只能透过OCI呼叫使用的重要功能。
当一个应用软件同时连接数个instance时,希望同时在所有instance执行一些动
作,nonblockingcall特别有用。还能让GUI设计师在使用者等待系统响应的时
候,显示动画转移使用者的注意。
使用OCI的代价就是开发的成本。一般来说,就算是同样的程序代码,使用OCI都
会比使用Oracleprecompiler还长。此时,必须要衡量使用OCI的好处和代价,甚
至考虑同时使用两个方法。早期Oracle版本,执行使用OCI编译的程序,会比
Pro*C或Pro*COBOL所产生的程序慢上好几倍。虽然这个问题已经在7.0版解决
了,但是使用者仍不会因为使用OCI、而增加系统效能。
版本7.3
7.3版引进相当多新的功能。事实上,Oracle已经说明7.3版不被称为Oracle8的
唯一理由是因为,Oracle8已经被保留作为对象导向化的名称。
Sharedpool
Oracle7.3重新设计sharedpool,不仅在数据字典中管理触发程序,并且改善预储
程序的高速缓存管理。这么做解决许多效能上的问题,特别是有关触发程序及预
储程序方面的问题。
数值分布状况
7.3版的cost-basedoptimizer能读取每个作为索引字段数值的分布状况,甚至那些
未作为索引的字段也可以。这个功能是不错,但也引发至少三个问题:
第一,数值分布状况(valuehistogram)是以字段值,而非key值作为数值分布状
况。当然,对于单一字段的索引来说,这两者是一样的,但是,对复合索引
(concatenatedindex)所代表的意义就大不相同了。如此一来,cost-basedoptimizer

为什么「设计」如此重要?/55
会在某些情况无法得到正确数据作判断,而不知道是否使用复合索引。常见的例子
就是,被当成索引的第一个字段数值分布会很平均,但是复合索引的数值分布却呈
现高度的集中(highlyselective)的状态。
第二,7.3版查询最佳化处理器仍然没有好的模式,可以将CPU执行SQL指令的
负荷考虑进去。即使使用索引搜寻,速度会较快,早期cost-basedoptimizer的版
本仍常使用fulltablescan。在7.3.2版一系列测试中,某些使用索引搜寻会比较快
的情况下,optimizer采取fulltablescan搜寻方式;相反的情况也会发生,像是使
用fulltablescan搜寻方式会较快的情况下,这版的optimizer有时会使用索引搜
寻。(那还不如不要optimizer)。
第三,Oracle在使用连结变量(bindvariable)查询时,并没有使用字段数值的分
布作最佳化。比如说这种查询:
SELECTCOUNT(*)FROMtradesWHEREcurrency='NOK'.
如果我们知道NOK的数值分布(如NOK的值出现不到1.25%),要对这样的查询作
最佳化就很简单。但如果同样的数值分布告诉我们USD的值出现超过85%的话,
那么对于底下的查询就没有正确的最佳化方法。
SELECTCOUNT(*)FROMtradesWHEREcurrency=:curr;
而且,还必须在选择存取方法之前,先知道连结变量的值,才可以选择好的读取方
案。这是一个特别的问题,因为多年来,程序设计师发现使用连结变量(如上例中
的:curr)是较好的方法,节省SQL指令解析的时间、且提升sharedpool。这是
因为Oracle保持传统最佳化的方法-在第一次执行前,先对个别的SQL指令
作最佳化,后来的执行则会使用同样的查询计划(queryplan)。
无限制的延展空间
7.3版数据库所有的对象(包括表格、索引、丛集、rollbacksegment、temporary
segment)都可有不限的延展空间(unlimitedextent)。对于DBA来说,特别有帮
助。对设计师,这个功能则减少在空间配置上,可能发生错误的后果。

56/第二章
Bitmap索引
7.0版之前的Oracle只支持B-Tree索引。7.0版本则加入Hashcluster,但对设计
师来说,并没有明显的吸引力。Hashcluster似乎很少人在用,而且有人说使用
后,并没有得到预期效能。
在7.3.3版中,Oracle在服务器中支持bitmap索引(在SQL*TextRetrieval产品中
已使用好几年了),这对字段中可能出现的数值很少时,特别有效率(例如,指向
代码表格的外来键(foreignkey)),特别是在WHERE子句中使用AND运算的时
候。
新的join策略

Oracle对于equijoin【译注:equijoin就是在WHERE子句中为WHEREX=Y形式的
join】的传统join方式是使用巢状循环(nestedloopjoin)以及排序合并(sort
mergejoin)。这两种方法都相当有效率。但在某些情况下,如数据仓储及OLAP应
用程序,就有相当差的效能。
7.3版,Oracle提供「starjoin」及「hashjoin」的功能。查询最佳化处理器可以选
择分别使用两者或者同时使用。
Starjoin是将许多要查询的表格join成fact表格,这些要查询的表格和join后的
大表格间,存有关连性的条件。但是,每个表格不是由其它表格合并而成的。Star
join正是利用这种缺乏相互关系的条件,从要查询的表格中,产生含有所有合格资
料列(row)的卡式积(Cartesianproduct),然后,再join到fact表格上。Star
join非常适合数据仓储的应用。
有时候,从数据量的角度看,hashjoin相当好用。因为hashjoin让数据库引擎利
用hashing的技术来代替执行完整的排序,然后再执行合并的工作。
在一般应用程序中,也可透过手动方式使用starjoin,只要在一个自行定义的表格
?,建立各个表格的卡式积。在某些特殊的情况下,可以得到许多效能上的好处,
而且比传统Oracleoptimizer采用的方法好的多。

为什么「设计」如此重要?/57
网络运算架构
自从Oracle从原本的SQL*Net发展出网络产品后,它们的通讯能力扩张到不仅可
以执行客户端发出的SQL指令,还能够传递远程过程调用(remoteprocedure
call,简称RPC)。
在新的网络运算架构(NetworkComputingArchitecture,简称NCA)(如图2-1)
中,Oracle发行一系列接口标准,让卡匣(cartridge)或namedservice回应其它
卡匣的请求。这些卡匣(含括传统的客户端及服务器),并不是以阶层式的架构存
在,而是在共同连接层中相互运作。显然地,这与WWW概念类似。事实上,Java
也是可以作为撰写卡匣的语言。我们还期望Oracle会将本身NetworkComputer
(NC)提升为主要的使用者接口装置,来执行用Java写的卡匣。
图2-1:Oracle的网络运算架构
也许对设计师来说,更感兴趣的会是能透过PL/SQL呼叫,对其它的卡匣作请求
(request)。这个功能对本书是相当新的,因为我们未能有机会使用这种功能建立一
些东西。不过,它似乎提供一个弹性的方法,让我们能够从Oracle呼叫任何卡匣
的服务。因为,传统的设计限制我们只能使用SQL或PL/SQL才能够呼叫其它
Oracleinstance,且必须透过Oracle的gateway服务,才能呼叫其它数据库引擎。

58/第二章
许多厂商已经和Oracle签约,作为开发各种卡匣的协力厂商,我们对这样的发展
相当感兴趣。写本书第二版时,相信会有许多关于使用数据卡匣(datacartridge)
的心得,以及许多使用Oracle8新功能优缺点的描述。
Oracle8简介
许多Oracle观察者,预期在一九九六年十一月旧金山,举行联合OracleOpen
World及InternationalOracleUserGroup的会议中,Oracle会发布有关Oracle8的
讯息,但是该会议中却没有有关Oracle8的内容或是发行日期。虽然许多客户及协
力厂商拥有Oracle8的beta测试版,但经验告诉我们,正式版通常和beta版相差
甚远。有些beta版中的功能很可能会因为反应不良而腰斩,更有可能会因为使用
者的关系,而有较大改变。基于这个原因,我们强烈建议设计者不要将beta版的
功能作为决策的基础。
这些建议对Oracle8来说,更显得重要,因为Oracle8许多新功能,主要是设计用
来支持比现行更大的数据库。更让人期望的是Oracle8应该会在SQL中支持对象
导向(ObjectOrientation,简称OO)。
分割
这个版本最重要的新功能是,能宣告key-partitioned表格。Key-partitioned表格是
指,将逻辑的表格定义成为一些字段与限制(constraint),定义一些实体的分割
(partition)储存该表格,并指定一个固定范围的值作为partitionkey。在本书,我
们会提供一些参考的步骤,协助Oracle7的设计师达到许多分割表格(partitioned
table)所赋予的优点。显然地,如果能在数据库服务器中直接支持是最理想的。最
主要的目标是要将partition(而不是表格本身)作为recovery(回复)的基本单
位,并且让分割索引配合optimizer来得到索引结构的最大好处。
这里有个问题是,uniquekey必须在表格层次(level)中执行,而非分割层次。假
如partitionkey(决定一笔数据储存在那一个partition当中的字段)既是主键
(primarykey)、也是其它所有的唯一键(uniquekey),那就没有太大的问题。但如
果不是这种情形,就需要一个表格层次的索引保证字段的唯一性。

为什么「设计」如此重要?/59
作为一个设计师还是会有需要妥协的地方。在本例中,必须在表格层次索引的缺点
(建立的时间、所需要的空间和单一节点损坏,会对所有partition造成影响),及
不使用限制(constraint)可能破坏数据整合性上做一个决策。
对Oracle7的向前兼容性
目前我们发现唯一一个潜在性兼容问题,是rowid的格式作很大改变,以至于现在
有两种rowid格式(format)。较短的格式是用来参考已知名称的表格中的一笔资
料列(row);而较长的格式则用来参考数据库中的任何一笔数据。
虽然这些改变一定会造成很多DBA所写的手稿(script)无法继续使用,但是应该
只有少量的应用程序会用到rowid的内部结构。较短的格式(通常会伴随着
SELECTROWID...FORUPDATE出现)可以储存在旧格式中的18byte。那些使用
rowid内部格式的应用程序大概都应该值得升级到Oracle8吧!
但是...
再重复一次,在Oracle8这节开头所提到的讯息,虽然乍看下非常的吸引人,但是
你必须要在将它们应用到项目前考虑清楚。至少在应用到成品之前,必须先等到
Oracle发行正式版,并且在实际的营运环境下运作测试过,才能预期它们所带来的
影响。
那么本书当中Oracle7的内容怎么办?会不会被Oracle8所取代?我们现在的感觉
是Oracle8并不会造成本书的内容有太大的改变。但我们希望新功能能够对你的设
计问题提供更好的解决方案。

60/第二章

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

第67期:Neo4j图数据库平台架构最佳实践
【微学堂】10月18日 20:00(周四)

当下,数据的规模和类型每时每刻都在呈几何级数的增长,仅能够管理大量的数据是不够的,关键是能从海量数据中发掘出有用的信息,特别是数据之间的关联,能高效存储和处理数据之间关联的新型数据库为图数据库。 本讲座将介绍Neo4j图数据库的基本概念、设计特点、架构和经典应用场景实战分享。

进入课堂>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表