oracle专家高级编程 中文第一章

1第1章开发成功的Oracle应用程序我花了大量时间使用Oracle数据库软件，更确切地讲，一直在与和使用Oracle数据库软件的人打交道。在过去的18年间，我参与过许多项目，有的相当成功，有点却彻底失败，如果把这些经验用几句话来概括，可以总结如下：q基于数据库（或依赖于数据库）构建的应用是否成功，这取决于如何使用数据库。另外，从我的经验看，所有应用的构建都围绕着数据库。如果一个应用未在任何地方持久地存储数据，很难想象这个应用真的有用。q应用总是在“来来去去”，而数据不同，它们会永远存在。从长远来讲，我们的目标并不是构建应用，而应该是如何使用这些应用底层的数据。q开发小组的核心必须有一些精通数据库的开发人员，他们要负责确保数据库逻辑是可靠的，系统能够顺利构建。如果已成事实（应用已经部署）之后再去调优，这通常表明，在开发期间你没有认真考虑这些问题。这些话看上去再显然不过了。然而，我发现太多的人都把数据库当成是一个黑盒（blackbox），好像不需要对它有输入了解。他们可能有一个SQL生成器，认为有了这个工具，就不需要再费功夫去学SQL语言。也可能认为使用数据库就像使用平面文件一样，只需要根据索引读数据就行。不管他们怎么想，有一点可以告诉你，如果按这种思路来考虑，往往会被误导：不了解数据库，你将寸步难行。这一章将讨论为什么需要了解数据库，具体地讲，就是为什么需要理解以下内容：q数据库的体系结构，数据库如何工作，以及有怎样的表现。q并发控制是什么，并发控制对你意味着什么。q性能、可扩缩性和安全性都是开发时就应该考虑的需求，必须适当地做出设计，不要指望能碰巧满足这些需求。q数据库的特性如何实现。某个特定数据库特性的实际实现方式可能与你想象的不一样。你必须根据数据库实际上如何工作（而不是认为它应该如何工作）来进行设计。q数据库已经提供了哪些特性，为什么使用数据库已提供的特性要优于自行构建自己的特性。q为什么粗略地了解SQL还不够，还需要更深入地学习SQL。qDBA和开发人员都在为同一个目标努力，他们不是敌对的两个阵营，不是想在每个回合中比试谁更聪明。初看上去，好像要学习的东西还不少，不过可以做个对照，请考虑这样一个问题：如果你在一个全新的操作系统（operatingsystem，OS）上开发一个高度可扩缩的企业应用，首先要做什么？希望你的答案是：“了解这个新操作系统如何工作，应用在它上面怎样运行，等等”。如果不是这样，你的开发努力将会付诸东流。例如，可以考虑一下Windows和Linux，它们都是操作系统。能为开发人员提供大致相同的一组服务，如文件管理、内存管理、进程管理、安全性等。不过，这两个操作系统的体系结构却大相径庭。因此，如果你一直是Windows程序员，现在给你一个任务，让你在Linux平台上开发新应用，那么很多东西都得从头学起。内存管理的处理就完全不同。建立服务器进程的方式也有很大差异。在Window下，你会开发一个进程，一个可执行程序，但有许多线程。在Linux下则不同，不会开发单个独立的可执行程序；相反，会有多个进程协作。总之，你在Windows环境下学到的许多知识到了Linux上并不适用（公平地讲，反之亦然）。要想在新平台上也取得成功，你必须把原来的一些习惯丢掉。在不同操作系统上运行的应用存在上述问题，基于不同数据库运行的应用也存在同样的问题：你要懂得，数据库对于成功至关重要。如果不了解你的数据库做什么，或者不清楚它怎么做，那你的应用很可能会失败。如果你认为应用在SQLServer上能很好地运行，那它在Oracle上也肯定能很好地工作，你的应用往往会失败。另外，公平地讲，反过来也一样：一个Oracle应用可能开发得很好，可扩缩性很好，但是如果不对体系结构做重大改变，它在SQLServer上不一定能正常运行。Windows和Linux都是操作系统，但是二者截然不同，同样地，Oracle和SQLServer（甚至可以是任何其他数据库）尽管都是数据库，但二者也完全不同。1.1我的方法在阅读下面的内容之前,我觉得有必要先解释一下我的开发方法。针对问题，我喜欢采用一种以数据库为中心的方法。如果能在数据库中完成，我肯定就会让数据库来做，而不是自行实现。对此有几个原因。首先，也是最重要的一点，我知道如果让数据库来实现功能，应用就可以部署在任何环境中。据我所知，没有哪个流行的服务器操作系统不支持Oracle；从Windows到一系列UNIX/Linux系统，再到OS/390大型机系统，都支持Oracle软件和诸多选项。我经常在我的笔记本电脑上构建和测试解决方案，其中在Linux或WindowsXP上（或2者使用VMware来模拟这些环境）运行Oracle9i/Oracle10g。这样一来，我就能把这些解决方案部署在运行相同数据库软件但有不同操作系统的多种服务器上。我发现，如果某个特性不是在数据库中实现，要想在希望的任何环境中部署这个特性将极其困难。Java语言之所以让人趋之若鹜，一个主要原因就是Java程序总在同样的虚拟环境〔即Java虚拟机（JavaVirtualMachine，JVM）〕中编译，这使得这些程序的可移植性很好。有意思的是，也正是这个特性让我对数据库着迷不已。数据库就是我的“虚拟机”，它也是我的“虚拟操作系统”。前面已经提到，我采用的方法是尽可能在数据库中实现功能。如果数据库环境无法满足我的需求，我也会在数据库之外使用Java或C来实现。采用这种方式，操作系统的复杂细节对我来说几乎是隐藏的。我要了解我的“虚拟机”如何工作（也就是Oracle如何工作，有时可能还需要用到JVM），毕竟，起码要了解自己使用的工具才行。不过，至于在一个给定的操作系统上怎么才能最好地工作，这些都由“虚拟机”来负责。所以，只需知道这个“虚拟操作系统”的细节，我构建的应用就能在多种操作系统上很好地工作和扩缩。我并不是暗示你可以完全忽略底层的操作系统。不过，作为一个构建数据库应用的软件开发人员，还是尽量避开它比较好，你不必处理操作系统的诸多细微之处。应该让你的DBA（负责运行Oracle软件）来考虑如何适应操作系统（如果他或她做不到，你就该换个新的DBA了！）。如果你在开发客户/服务器软件，而且大量代码都是在数据库和虚拟机（VM；JVM可能是最流行的虚拟机了）之外实现，那你还得再次考虑你的操作系统。对于开发数据库软件，我有一套很简单的哲学，这是我多年以来一直信守的思想：q如果可能，尽量利用一条SQL语句完成工作。q如果无法用一条SQL语句完成，就通过PL/SQL实现（不过，尽可能少用PL/SQL！）。q如果在PL/SQL中也无法做到（因为它缺少一些特性，如列出目录中的文件），可以试试使用Java存储过程来实现。不过，有了Oracle9i及以上版本后，如今需要这样做的可能性极小。q如果用Java还办不到，那就在C外部过程中实现。如果速度要求很高，或者要使用采用C编写的一个第三方API，就常常使用这种做法。q如果在C外部例程中还无法实现，你就该好好想想有没有必要做这个工作了。在这本书中，你会看到我是怎样将上述思想付诸实现的。我会尽可能使用SQL，充分利用它强大的新功能，如使用分析函数来解决相当复杂的问题，而不是求助于过程性代码。如果需要，我会使用PL/SQL和PL/SQL中的对象类型来完成SQL本身办不到的事情。PL/SQL发展至今已经有很长时间了，它得到了长达18年的调整和优化。实际上，Oracle10g编译器本身就首次重写为一个优化编译器。你会发现，没有哪种语言能像PL/SQL这样与SQL如此紧密地耦合，也没有哪种语言得到如此优化，可以与SQL更好地交互。在PL/SQL中使用SQL是一件相当自然的事情，而在几乎所有其他语言（从VisualBasic到Java）中，使用SQL感觉上都很麻烦。对于这些语言来说，使用SQL绝对没有“自然”的感觉；它不是这些语言本身的扩缩。如果PL/SQL还无法做到（这在Oracle9i或10g中可能相当少见），我们会使用Java。有时，如果C是惟一的选择，或者需要C才能提供的高速度，我们也会用C来完成工作，不过这往往是最后一道防线。随着本地Java编译（nativeJavacompilation）的闪亮登场（可以把Java字节码转换为具体平台上特定于操作系统的对象码），你会发现，在许多情况下，Java与C的运行速度相差无几。所以，需要用到C的情况越来越少。1.2黑盒方法根据我个人的第一手经验（这表示，在学习软件开发时我自己也曾犯过错误），我对基于数据库的软件开发为什么如此频繁地遭遇失败有一些看法。先来澄清一下，这里提到的这些项目可能一般不算失败，但是启用和部署所需的时间比原计划多出许多，原因是需要大幅重写，重新建立体系结构，或者需要充分调优。我个人把这些延迟的项目称为“失败”，因为它们原本可以按时完成（甚至可以更快完成）。数据库项目失败的最常见的一个原因是对数据库的实际认识不足，缺乏对所用基本工具的了解。黑盒方法是指有意让开发人员对数据库退避三舍，甚至鼓励开发人员根本不要学习数据库！在很多情况下，开发人员没有充分利用数据库。这种方法的出现，原因可以归结为FUD〔恐惧（fear）、不确定（uncertainty）和怀疑（doubt）〕。一般都认为数据库“很难”，SQL、事务和数据完整性都“很难”。所以“解决方法”就是：不要卷入难题中，要知难而退。他们把数据库当成一个黑盒，利用一些软件工具来生成所有代码。他们试图利用重重保护与数据库完全隔离，以避免接触这么“难”的数据库。我一直很难理解这种数据库开发方法，原因有二。一个原因是对我来说，学习Java和C比学习数据库基本概念要难多了。现在我对Java和C已经很精通，但是在能熟练使用Java和C之前我经受了许多磨炼，而掌握数据库则没有这么费劲。对于数据库，你要知道它是怎么工作的，但无需了解每一个细节。用C或Java编程时，则确实需要掌握每一个细枝末节，而这些语言实在是很“庞大”。让我无法理解这种方法的另一个原因是，构建数据库应用时，最重要的软件就是数据库。成功的开发小组都会认识到这一点，而且每个开发人员都要了解数据库，并把重点放在数据库上。但我接触到的许多项目中，情况却几乎恰恰相反。例如，下面就是一种典型的情况：3q在构建前端所用的GUI工具或语言（如Java）方面，开发人员得到了充分的培训。在很多情况下，他们会有数周甚至数月的培训。q开发人员没有进行过Oracle培训，也没有任何Oracle经验。大多数人都没有数据库经验，所以并未理解如何使用核心的数据库构造（如各种可用的索引和表结构）。q开发人员力图谨守“数据库独立性”这一原则，但是出于许多原因，他们可能做不到。最明显的一个原因是：他们对于数据库没有足够的了解，也不清楚这些数据库可能有什么区别。这样一个开发小组无法知道要避开数据库的哪些特性才能保证数据库独立性。q开发人员遇到大量性能问题、数据完整性问题、挂起问题等（但这些应用的界面往往很漂亮）。因为出现了无法避免的性能问题，他们把我找来，要求帮助解决这些难题。我最早就是从构建数据库独立的应用做起的（从某种程度上讲，在ODBC问世之前，我就已经编写了自己的ODBC驱动程序），我知道哪些地方可能会犯错误，因为我以前就曾犯过这些错误。我总会查看是否存在下面这些问题：存在效率低下的SQL；有大量过程性代码，但这些工作原本用一条SQL语句就足够了；为了保持数据库独立性，没有用到新特性（1995年以后的新特性都不敢用），等等。我还记得这样一个特例，有个项目找我来帮忙。当时要用到一个新命令，但我记不清那个新命令的语法。所以我让他们给我拿一本SQLReference手册，谁知他们给了我一本Oracle6.0文档。那个项目开发用的是7.3版本，要知道，6.0版本和7.3版本之间整整相差5年！7.3才是所有开发人员使用的版本，但似乎谁都不关心这一点。不用说他们需要了解的跟踪和调优工具在6.0版本中甚至不存在。更不用说在这5年间又增加了诸如触发器、存储过程和数百个其他特性，这些都是编