最近评论
正在载入评论列表...
我花了大量时间使用Oracle数据库软件，更确切地讲，一直在与使用Oracle数据库软件的人打交道。在过去的18年间，我参与过许多项目，有的相当成功，有的却彻底失败，如果把这些经验用几句话来概括，可以总结如下：
q 基于数据库（或依赖于数据库）构建的应用是否成功，这取决于如何使用数据库。另外，从我的经验看，所有应用的构建都围绕着数据库。如果一个应用未在任何地方持久地存储数据，很难想象这个应用真的有用。
q 应用总是在“来来去去”，而数据不同，它们会永远存在。从长远来讲，我们的目标并不是构建应用，而应该是如何使用这些应用底层的数据。
q 开发小组的核心必须有一些精通数据库的开发人员，他们要负责确保数据库逻辑是可靠的，系统能够顺利构建。如果已成事实（应用已经部署）之后再去调优，这通常表明，在开发期间你没有认真考虑这些问题。
这些话看上去再显然不过了。然而，我发现太多的人都把数据库当成是一个黑盒（black box），好像不需要对它有深入了解。他们可能有一个SQL生成器，认为有了这个工具，就不需要再费工夫去学SQL语言。也可能认为使用数据库就像使用平面文件一样，只需要根据索引读数据就行。不管他们怎么想，有一点可以告诉你，如果按这种思路来考虑，往往会被误导：不了解数据库，你将寸步难行。这一章将讨论为什么需要了解数据库，具体地讲，就是为什么需要理解以下内容：
q 数据库的体系结构，数据库如何工作，以及有怎样的表现。
q 并发控制是什么，并发控制对你意味着什么。
q 性能、可扩缩性和安全性都是开发时就应该考虑的需求，必须适当地做出设计，不要指望能碰巧满足这些需求。
q 数据库的特性如何实现。某个特定数据库特性的实际实现方式可能与你想象的不一样。你必须根据数据库实际上如何工作（而不是认为它应该如何工作）来进行设计。
q 数据库已经提供了哪些特性，为什么使用数据库已提供的特性要优于自行构建自己的特性。
q 为什么粗略地了解SQL还不够，还需要更深入地学习SQL。
q DBA和开发人员都在为同一个目标努力；他们不是敌对的两个阵营，不是想在每个回合中比试谁更聪明。
初看上去，好像要学的东西还不少。不过可以做个对照，请考虑这样一个问题：如果你在一个全新的操作系统（operating system，OS）上开发一个高度可扩缩的企业应用，首先要做什么？希望你的答案是“了解这个新操作系统如何工作，应用在它上面怎样运行，等等”。如果不是这样，你的开发努力就会付诸东流。
例如，可以考虑一下Windows与Linux。它们都是操作系统，能为开发人员提供大致相同的一组服务，如文件管理、内存管理、进程管理、安全性等。不过，这两个操作系统的体系结构却大相径庭。因此，如果你一直是Windows程序员，现在给你一个任务，让你在Linux平台上开发新应用，那么很多东西都得从头学起。内存管理的处理就完全不同。建立服务器进程的方式也有很大差异。在Windows下，你会开发一个进程、一个可执行程序，但有许多线程。在Linux下则不同，不会开发单个独立的可执行程序；相反，会有多个进程协作。总之，你在Windows环境下学到的许多知识到了Linux 上并不适用（公平地讲，反之亦然）。要想在新平台上也取得成功，你必须把原来的一些习惯丢掉。
在不同操作系统上运行的应用存在上述问题，基于不同数据库运行的应用也存在同样的问题：你要懂得，数据库对于成功至关重要。如果不了解你的数据库做什么，或者不清楚它怎么做，那你的应用很可能会失败。如果你认为应用在SQL Server上能很好地运行，那它在Oracle上也肯定能很好地工作，你的应用往往会失败。另外，公平地讲，反过来也一样：一个Oracle应用可能开发得很好，可扩缩性很好，但是如果不对体系结构做重大改变，它在SQL Server上不一定能正常运行。Windows和Linux都是操作系统，但二者截然不同；同样地，Oracle和SQL Server（甚至可以是任何其他数据库）尽管都是数据库，但二者完全不同。
1.1 我的方法
1.1 我的方法
在阅读下面的内容之前
, 我觉得有必要先解释一下我的开发方法。针对问题，我喜欢采用一种以数据库为中心的方法。如果能在数据库中完成，我肯定就会让数据库来做，而不是自行实现。对此有几个原因。首先，也是最重要的一点，我知道如果让数据库来实现功能，应用就可以部署在任何环境中。据我所知，没有哪个流行的服务器操作系统不支持Oracle；从Windows到一系列UNIX/Linux系统，再到OS/390大型机系统，都支持Oracle软件和诸多选项。我经常在我的笔记本电脑上构建和测试解决方案，其中在Linux或Windows XP上（或者使用VMware来模拟这些环境）运行Oracle9i/Oracle 10g。这样一来，我就能把这些解决方案部署在运行相同数据库软件但有不同操作系统的多种服务器上。我发现，如果某个特性不是在数据库中实现，要想在希望的任何环境中部署这个特性将极其困难。Java语言之所以让人趋之若鹜，一个主要原因就是Java程序总在同样的虚拟环境［即Java虚拟机（Java Virtual Machine，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年的调整和优化。实际上，Oracle 10g编译器本身就首次重写为一个优化编译器。你会发现，没有哪种语言能像PL/SQL这样与SQL如此紧密地耦合，也没有哪种语言得到如此优化，可以与SQL更好地交互。在PL/SQL中使用SQL是一件相当自然的事情，而在几乎所有其他语言（从Visual Basic到Java）中，使用SQL感觉上都很麻烦。对于这些语言来说，使用SQL绝对没有“自然”的感觉；它不是这些语言本身的扩缩。如果PL/SQL还无法做到（这在Oracle 9i或10g中可能相当少见），我们会使用Java。有时，如果C是惟一的选择，或者需要C才能提供的高速度，我们也会用C来完成工作，不过这往往是最后一道防线。随着本地Java编译（native Java compilation）的闪亮登场（可以把Java字节码转换为具体平台上特定于操作系统的对象码），你会发现，在许多情况下，Java与C的运行速度相差无几。所以，需要用到C的情况越来越少。
图书导读
