我从19xx年就开始编写PL/SQL代码。这意味着我已经编写了几万行的软件代码，但我确信，其中的绝大多数代码都非常拙劣，而且难以维护。

幸运地是，我发现找到并遵循编写出更好代码的新方法还为时不晚。就是在去年，我的代码质量有了显著改进；这些改进主要是由于制定了一些简单的规则，并像纪律一样加以遵守。

本文为PL/SQL新手及有经验的开发人员提出了四条建议；遵守其中任何一条，你的代码质量都会有提高。这四点建议都采纳，你可能会惊奇地猛然发现：你竟然是一个非常好的程序员，要远远超乎你的想象。

所有工作都独自完成

我们很少有人是孤立工作的；大多数PL/SQL开发工作是在相对较大的机构中进行的。但我们基本上还是在自己的小隔间里用自己的设备独自工作。几乎没有PL/SQL开发小组进行正规的代码复查或系统测试。

我不可能通过这篇文章改变你们开发小组的基本状态。因此，我仔细地选取出以下几点建议。实施其中任何一点并不需征得管理人员同意。不论你的小组是大是小，都不必让其中的每个人都赞同这些编码规则。你只需按以下建议来改变你的本人的编码方式：

1. 严格遵循命名约定，好像它们就是你的生命支柱。

2. 戒除编写SQL的嗜好：编写的SQL越少越好。

3. 使执行部分短小：告别“意大利面条式的代码”。

4. 找一位伙伴：非常赞同找个人来监督你的工作。

1. 遵循命名约定

如果你建立并严格遵循一套命名约定，特别是对于应用程序组件的，你就可以节省很多时间。

当然，遵循命名约定的想法并没有什么新意，你可能已经听烦了。所以我并不提出什么宏伟的命名计划，而是给出一些非常具体而明确的约定，然后证明这些约定会多么有用。

前几个月我一直在为PL/SQL开发人员设计、构建一种新工具。它名为Swyg(可以在中找到)，可以帮助程序员完成代码的生成、测试及重用的工作。它具有几个独特的组件。我为每个组件指定了一个由两个字母组成的缩写名称，如下所示：

◆SF-Swyg的基础部件

◆SM-Swyg的元数据

◆SG-Swyg的生成程序

◆SL-Swyg的代码库

◆ST-Swyg的单元测试

于是，我便遵循表1中的命名约定，同时使用这些缩写。遵循这些约定有什么好处呢?一般来讲，如果我要求一致的命名规则，我就可以更流畅更高效地编写代码。

明确地说，这些约定具有可预测性，意思是说我编写的SQL程序能生成有用的脚本。例如，通过使用表1中的约定，可以生成Swyg中所有基础包的安装脚本。执行这些工作的SQL*Plus脚本如清单1所示。这类脚本非常有用，因为它意味着我不必手动维护安装脚本。当我向Swyg方案中增加另一个表，并生成一组相关包时，我只要运行我的脚本，更新后的安装脚本便会跳出来。

2. 戒除编写SQL的嗜好

编写的SQL越少越好，这似乎与我们的直觉不太一致。对于PL/SQL开发人员来说，这是一个奇特的建议，因为PL/SQL的主要优点之一就是可以毫不费力地在代码中编写SQL语句。不过，这种简易性也是这种语言的一个致命的弱点。

可以将纯粹的SQL语句直接置于PL/SQL代码中，而无需JDBC或ODBC之类的中间层。因此，无论何时何地，PL/SQL开发人员只要需要SQL语句，他们通常就会向其应用程序代码中嵌入SQL语句。那么这样做有什么问题吗?

在PL/SQL代码中到处使用SQL语句必然会导致以下后果：

尽管实际表现不同，但同一逻辑语句仍会出现重复，从而导致过多的语法分析，且难于优化应用程序的性能。

暴露商务规则和方案。这直接在SQL语句中包含了执行商务规则的逻辑。这些规则总在变化，所以应用程序的维护成本会急剧增加。

当然，你要编写的每一个PL/SQL应用程序几乎都是基于基础表和视图的。你需要执行SQL语句。问题不在于是否执行，而是何时执行、如何执行。

如果你对数据结构进行封装，或者将它们隐藏于一个PL/SQL代码层(通常是一个代码包)之后，那么你的应用程序将会更健壮，而且你还会发现创建和维护变得更易多了。

我们来看一个简单的例子。 假定我需要编写一个处理某员工工作的程序。第一件事是获取该员工的全名，定义为“姓名逗号(，)姓”；然后我可以进行详细分析。清单2给出了这种情况下我很可能要编写的这类代码的一个示例。

一切似乎都是这么简单和直接；这些代码可能会有什么错误呢?实际上真是非常糟糕。最主要的是我暴露了一个商务规则：全名的结构。我可能要花费数小时来对此代码及其所基于的应用程序进行测试。但就在它刚刚投入使用时，我才知道客户会不断地打电话告诉我，实际上，他们的全名应该表示为“名空格姓”。

现在怎么办?搜索所有位于引号内的单个逗号?

现实的解决方案是使用隐藏所有细节、只提供一组预定义、预测试及预优化并能完成所有任务的程序包。清单3为基于封装代码重新编写的process_employee过程。hr_employee_tp包提供了用于定义保存姓名的局部变量的类型；hr_employee_rp包含有基于一种商务规则而返回全名的函数。

将显示PL/SQL语句灌入SQL代码很容易，同样，谈论封装这些语句是如何重要也不费劲。但另一方面，编写执行封装任务的代码却具有挑战性；甚至是不现实的。生成这些包或许更有意义。

几年前，我曾帮助构建这样一个生成程序。该程序段为PL/Generator，现在由Quest Software公司拥有，PL/SQL开发社区可以免费使用。你可以从我的网站

下载。要知道，其封装体系结构与我在前面所概括的约定不同。PL/Generator创建了一个单独的包，它包含了一个表的类型、查询和变化逻辑的全部内容。

当你不再编写太多的SQL，而是调用执行SQL的程序时，无论你是生成还是编写自己的定制封装，你的应用程序都会受益匪浅。

3. 使执行部分短小

面对现实：总是与我们的判断和最新的一系列新年决议相左，我们必须停止编写意大利面条式的代码：庞大而冗长，人们实际上不可能理解它们，更不用说维护或升级了。怎样才能避免“意大利面条”呢?

实际上，答案很简单：决不允许执行部分超过50或60行。这种大小使你能在一页纸或一个屏幕上查看该代码块的整个逻辑结构，这也意味着你可以真实地领会该程序的意图，而且完全凭直觉就能理解它。

你可能非常同意上述观点，但同时又嘲笑我的建议：程序代码永远不超过50行。没错，你应当嘲笑，因为这当然是不可能的。毫无疑问，你需要超过50行的可执行代码；问题是你把这些代码放在哪，以及你怎样加以组织。

如果采取以下做法，你的确能够应对各种复杂的要求，并把代码限制在50行以内：

将所有的商务规则和离散逻辑块置于其自已的程序(通常是函数)中，从而在任何可能的时候慎重地重用代码。

尽量使用在程序的声明部分定义的局部模块、过程和函数。

假定我在编制一个呼叫中心应用程序。我需要编写一个程序，它要满足下面的要求： “对于特定部门的每个员工，将其工作量(分派给该员工的呼叫次数)同该部门员工的平均工作量进行比较。如果某员工的工作量低于平均工作量，便将下一待处理呼叫分派给此人，并基于这种情况安排约定。”

我从以前的工作中获悉：我的朋友Claudia已经编写了一个分析包，它会返回工作量方面的信息。但是分派待处理呼叫和安排约定都是全新的工作，需求文档的其余部分对此进行了详细说明。

最初我想把这15页的内容全都看完，但我没有那样做。我使用了一种称为“逐步求精法”或“由顶向下设计”的技术，并先编写了清单4中的代码来实现该程序。

下面给出了清单4中最关键代码行的解释；由该程序(紧凑的执行部分)的最后开始，向上进行。这似乎有悖于直觉，但这的确是通读用逐步求精法编写的程序的最好方式。

第22～30行。用一个游标FOR循环(cursor FOR loop)来对指定部门的所有员工进行迭代处理。在第24～25行，利用分析包中的程序判定当前的员工是否工作量不足。在第27～28行，调用三个程序：assign_next_open_case、schedule_case和next_appointment。我还不知道怎样实现这些程序，但我知道它们通过其名称和参数表表达了需要事先完成的工作。

第10～19行。为第27～28行中的三个程序创建“stub”，也就是占位程序。注意，它们是局部模块，在assign_workload中进行定义，且不能从其他任何程序调用。

第5～8行。定义一个游标，以获得指定部门的所有员工。现在可以设法编译此代码。 对这样一个小程序成功完成编译好像是个小胜利，也的确如此。完成正确编译，然后是简单测试，然后增加一点代码，再进行正确编译，以此类推，诸如此类的小胜利缔造出构造精良的程序，而且会非常满意。

我还可以验证该分析程序是有效的，并且找出了要分派的任务适当雇员。这些工作全部完成后，我将从三个程序中挑出一个，比如assign_next_open_case，进行下一步或下一级别的精细设计。我要阅读该任务的文档，并在assign_next_open_case里编写一个简短的执行部分，它可反映该任务的概况。

很快，我的局部过程有了它自己的局部过程和函数，但在该过程的每一步，我的代码都很短、可读、易于测试、可根据需要进行调整。

4. 找一位好伙伴

计算机并不会编程，人才会。

有多少次你弯着腰、驼着背坐在计算机前，因无法找出代码中的错误而感到非常郁闷?先是几分钟过去了，接着又过了几小时。最后，对自己都厌烦了，感到非常失败，你把头伸出你的小隔间并请朋友过来帮你看一看。

通常会有下面三种情况之一出现：

当你的朋友从她的椅子上站起来时，一切都在瞬间变得非常清楚。

你的朋友瞥了一眼屏幕，马上就指出了问题所在。

你的朋友不负责该系统中你所做的部分，所以你必须说明你的程序在干什么。当你逐步讲解逻辑时，引起错误的问题所在会突然暴露在你面前。

事实就是自己很难调试自己的代码，因为你自己对它太投入、太专注了。

这个问题最好的解决办法是由开发经理创造这样一种文化：各种想法是共享的、不懂是可以原谅的并不会受到处罚、定期进行建设性的代码评审。不幸的是，这些文化上的改变是难以实现的。

与此同时，我建议在帮助改变你所在小组的文化的过程中你应起带头作用。找到另一位开发人员，最好比你经验丰富，并建立一种“伙伴”关系：在出现问题时，他可以充当你的参谋，当然，你也可以充当他的参谋。事前达成共识：不知道所有问题的答案并没有什么不对。

然后为你自己制定一条简单的规则：不要为一个错误苦思冥想超过半个小时。30分钟过去后，把你的伙伴叫过来，让人类心理学为你服务，而不是跟你作对。

获得一种新工作方式的四个步骤

本文为你提供了可以采取的用于改变你的编程体验四个步骤，而无须投资新的工具或改变整个小组的工作流程。这四步甚至可以不全部遵循，只要遵守一步都会让你受益。

【相关文章】

第二篇：oracle数据库索引的理解与总结

 索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。

  例如这样一个查询：SELECT * FROM TABLE1 WHERE ID = 44。如果没有索引，必须遍历整个表，直到ID等于44的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，直接在索引里面找44（也就是在ID这一列找），就可以得知这一行的位置，也就是找到了这一行。可见，索引是用来定位的。

  建立索引的目的是加快对表中记录的查找或排序。为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。

  虽然建立索引能加快对表中记录的查询或者排序速度，但是并不是索引建得越多越好，这就需要我们了解使用索引过程中，索引的一些优点以及缺陷：

  使用索引的好处：

创建索引可以大大提高系统的性能：

第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。

第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。

第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

  使用索引的一些不足：

第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。

第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

  索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：

·         在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；

·         在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；

·         在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；

·         在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；

·         在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

  同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：

·         对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

·         对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。

·         对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。

·         当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

  在表上创建索引需要综合考虑使用索引所带来的好处以及其影响，只有合理有效的使用索引才能利用索引提高数据的查询或者排序性能。

B 树索引用于在可比较大小的字段上创建索引，能享受索引好处的表达式形式应是基于关系操作符’<’、‘>’、’=’ 、‘>=’、‘=’、‘<=’的关系表达式，以及非通配符开始的LIKE 表达式（其形式为columnLIKE ‘xxx%’），B 树索引允许创建复合索引，即索引键字段数可以超过1 个，复合索引发挥作用的条件为：索引键字段的中的最前面的一个或连续多个字段的表达式应作为“与”式的因子出现在条件表达式中，例如：假定在表的字段f1,f2,f3 上创建了复合索引，则语句…WHERE f1=?? And f2=??可以享受索引的好处，而语句…WHERE f2=?? Andf3=??则不能享受索引带来的好处，原因是最前面的f1 字段未出现在条件表达式中。

  R树索引只针对空间数据类型，而且只能针对单个字段，即不能创建R树复合索引或B树与R树的混合复合索引。在以空间关系作为条件的查询中，除了"相离"（DISJOINT）关系不能享受R树索引带来的好处外，其余空间关系基本都能从R树索引中得到好处。

  全文索引只针对文本类数据类型如：CHAR，VARCHAR,以及大对象中的文本等，若没有全文索引，则这类数据只能使用B 树索引，B树索引能发挥作用的条件为：条件表达式中与索引字段相关的子表达式应是基于关系操作符’<’、‘>’、’=’ 、‘>=’、‘=’、‘<=’的关系表达式，以及非通配符开始的LIKE 表达式（其形式为column LIKE ‘xxx%’），但在对文本进行检索时，通常会以文本中包含有哪些关键词作为检索的条件，传统关系表达式中只有形式为column LIKE ‘%xxx%’的关系表达式能表达查询的意图，并能得到预想的结果。但以该形式的表达式为条件表达式的查询只能使用顺序扫描，即对全表进行扫描，而且在对全表的每一记录的文本字段进行测试时，还应对文本字段的全部进行关键词匹配扫描，显然，涉及到的数据量和运算强度都非常大，对于巨型表而言，经常性地全文搜索查询会使系统不堪重负。针对以上应用情况，DBMS 采用全文索引解决查询性能问题。

  位图索引主要针对大量相同值的列而创建(例如：类别，操作员，部门ID,库房ID等)。位图索引可以提高基数比较小的表的查询速度，这主要是因为在创建位图索引的时候，数据库往往会对整个表进行扫描，并为索引列的每个取值建立一个位图(位图索引的名字也由此而来)。在这个位图中，为表中的每一行使用一个位元来表示该行是否包含该位图的索引列的取值。位元到行的ROWID的对应关系通过位图索引中的应收函数来完成。如此的话，位图索引就能够以一种完全不同的内部机制来完成与B树索引相同的功能。