前言 本书的要旨是，用Transact-SQL创建存储过程就如同用任何其他语言开发程序。如同用其他程序设计语言成功开发所需要的那样，创建存储过程需要同样的技巧、规划、体察入微和对技术的总体把握。为了掌握Transact-SQL，人们必须首先掌握软件开发的基础，然后在这种基础上，将Transact-SQL作为一种程序设计语言使用。本书教您如何实现该任务。 如果您是一位SQL Server初学者，也许有比本书更好的书可以向您介绍Transact-SQL存储过程程序设计。本书实际上适合中-高级开发人员。它假设您已经知道如何编写Transact-SQL查询程序，如何创建存储过程。除了某些讨论开始时的介绍性说明，本书很少提供入门级的指导。它针对具备中高级技术的开发人员，他们希望成为更好的存储过程程序员—— 希望学习更高级别的与Transact-SQL、存储过程程序设计和XML相关的高级软件技术。 笔者的前一本书The Guru’s Guide to Transact-SQL的卷首题词引自我的一位朋友—— 知名作家和演讲者Joe Celko。为了掌握诸如SQL之类的非过程化语言，抛弃过程化程序设计是至关重要的。同时，我赞成Joe的观点：按照过程化方式编写Transact-SQL代码是编写理想的Transact-SQL代码的最大的惟一的障碍。当笔者写作第一部Guru’s Guide时，我坚信，之所以那些使用其他语言的称职开发人员在尝试编写Transact-SQL代码时会遇到困难的主要原因是，试图与使用C++的相同方式编写Transact-SQL。他们的整个方法都错了，我推理这也是他们会遇到问题的原因。我认为他们没有像数据库程序员那样思考；相反，他们是像传统程序员那样思考，这种思维方式不适于数据库程序设计。我认为是如此。 从那时开始，我改变了看法。我曾看过一个访谈，其中Edward Van Halen声称，一个乐队的音乐唱片是该乐队在特定时空(音乐上和其他方面)的快照，书籍也如此。The Guru’s Guide to Transact-SQL就是我大约在1998年和1999年的全部写照，其间我写作了该书。此后，我对过程化程序设计与Transact-SQL之间关系的思考有了些许进展(或者我倾向于这样思考)。为什么？还是让我给大家讲一则小故事吧…… 在我写作The Guru’s Guide to Transact-SQL一书的两年期间的某个时候，该书的某位技术审阅者给我写信，询问几年前我为自己在Sybase Developer’s Journal的专栏所写的一篇介绍Transact-SQL中某些bitmask技巧的文章。他想要知道我是否给他寄该文的一个副本，因为他正在从事某些与bitmask相关的工作，并且想要使用我曾介绍过的某项技术。我在那篇文章中找遍了也没有在我所使用的各种计算机上发现相关内容。我写那些内容的机器已经很久不用了，该机器我进行了磁带备份—— 所以那些内容一定还在最初的位置上。 最终通过在互联网上的搜索找到了这篇老古懂，并将它转寄给需要它的同事。出于某种兴趣，我在自己的桌前坐下并阅读这篇文章片刻(大多数作者真正喜欢阅读自己曾写过的东西，不管它是多么古老，也不管它到底讲什么)。我独自思忖：是什么使我对Transcact-SQL中这种bit-twiddling技术着迷？为什么开始时我要考虑这些技术？我想要知道对这篇文章中这种技术进行探讨的原因。我的答案是，如果我能指出探讨这种技术的原因和方式，也许我就能揭开进行这种创新的秘密，或至少找出这种困惑的原因。也许我就会作为一名更高级的Transact-SQL程序员。 我为此考虑了几天，最后想到了提出这种bit-twiddling技术的原因。我的结论是：我尽可能地要使自己相信这种想法都来自我自己，而我从Transact-SQL所获得的许多“发现”都是学术界间接传授的结果。这主要是源自我使用其他语言的经验，这种经验使我经过多年研究提出了许多具有创新的编码技术。我对Transact-SQL所做的大部分发现源自我使用传统的程序设计语言(诸如Pascal、C/C++、汇编语言和其他语言)进行工作时在我的大脑中形成的雏形。我意识到在Transact-SQL程序设计这个相对较新的领域内，很少有真正具有创新意义的技术产生。毕竟像C和Pascal之类的语言比Transact-SQL早出现许多年—— 而像COBOL和BASIC之类的语言甚至更早。我们看到的不是计算领域的新问题，而是对同样的旧问题的新的解决方案。在Transact-SQL或SQL Server出现以前，人们已经解决这些问题很长时间了。当然，在软件工程领域内的大部分发现已经出现，而我们对Transact-SQL的创新成果只是在前人基础上努力的 结果。 Andrew Hunt和Dave Thomas在Pragmatic Programmer一书中强烈推荐渴望成为好的程序员的人每年应至少学习一门新的程序设计语言。我这里也作此推荐。如果您想精通Transact-SQL存储过程程序设计，就应该首先精通程序设计本身。程序设计、编码、软件工程—— 无论您如何称呼，都需要很长时间和需要掌握许多语言才能精通。像一个学习军事艺术的人在能获得高级地位前必须首先精通各方面的军事艺术一样。一个要精通Transact-SQL的程序员通常在希望能精通Transact-SQL前必须精通程序设计的各个方面。 各学科共同努力的结果所产生的美好前景和交叉性知识的传播，促使大学为学生讲授除主要研究领域外其他领域的知识。通过研究其他人做事的方式，您会看出在您的领域和其他领域间的许多相似点和差异性，您会对这些相似和差异有深刻的洞察，您会学会可能是以一种以前没有尝试过的方式把您在某方面所发现的东西应用到完全在您的领域外的其他领域。换句话说，您学会了创新。通过规纳各大学所持的观点，您对自己领域的理解会更加具有整体性：您开始更深刻地理解其哲学意义，并领会它适应事物实质性的时机。 我认为通过研究SQL Server之外的语言和技术也可获得同样的洞察力。即使我没有在汇编语言方面做过什么工作，即使没有对类似Steve Gibson这样的高手的工作进行过研究，我也不会对我最初写的那篇文章中的bit-twiddling技术目瞪口呆。但是如果没有我在Pascal和Delphi方面的工作，如果没有对如Anders Hejlsberg和Kim Kokkonen这样高手的代码进行过研究，我就不会在研究多年的Transact-SQL方面提出许多好的技术，包括您在本书中所看到的许多数据操作过程。我对Transact-SQL中一般设计模式的研究，受到Erich Gamma及其同事的Design Patterns 一书的鼓舞，在我使用C++和Object Pascal进行工作时总把该书放在手边。Brian Kernighan和Rob Pike的The Parctice of Programming一书对我的程序设计习惯产生很大的影响。因为Steve McConnell的After the Gold Rush一书和Kent Beck的Extreme Programming Explained一书的影响，我也是一贯支持测试的。另外，由于受Martin Fowler的Refactoring:Improving the Design of Existing Code一书的影响，我也非常赞同再评估的价值。本书讨论的许多算法受到Donald Knuth的三卷书The Art of Computer Programming和Jon Bentley的Programming Pearls一书以及许多其他书籍的启发。 这些书本身没有一本是关于Transact-SQL甚至是SQL Server的。他们也都未能阐述很容易就被转换成类似SQL的面向集合的语言的技术。然而，它们是关于程序设计的，我在其他语言方面的工作从中获得了许多知识。我从各学科间的工作中受益、我也从我在使用Transact-SQL和使用其他语言的交叉工作中受益。而且从这项工作为程序员提供的观点中受益。我认为您也会如此。 因此，不是说为了精通Transact-SQL就必须放弃那种沉重的过程性程序设计，我反而鼓励您尝试采用其他的语言和工具。每年学一种—— 它可以是您还没掌握的任何一种语言或工具 —— 如Visual Basic、Delphi、Ruby、C#，C++或Java等等。使用新语言来完成几个项目，理想情况是(但不是必需的)以某种方式将之跟SQL Server结合起来一起进行。购买所需的书籍，阅读新闻报导，进行研究，构建自己的软件。您会很惊奇地发现您竟学会了这么多的程序设计知识，作为开发人员的经验也在不断增长。 然后，有时通过这些研究项目，考虑一下如何把所学到的知识应用到Transact-SQL开发工作中。SQL Server如何采纳您正在研究的以工具为特色的语言元素呢？它又是如何实现您在新语言中发现的特别有用的功能呢？区别在哪里？比如说，OLE自动化在Transact-SQL和Delphi中的差别何在？假定Transact-SQL 像所有的SQL Server一样，都由C和C++编写，哪种语言声明会更符合其最初状态？ 这样困惑了几年后，在您获得了SQL Server之外世界的实际经验后，您就会在掌握Transact-SQL和存储过程程序设计过程中很顺利地获得必要的工具。您会把软件工程视作一项纪律；您会因此而爱上程序设计这项工作。这是精通任何程序设计语言包括Transact-SQL的关键所在。 因此，尽管我对Joe Celko仍有歉意，但我也不再相信过程性程序设计是好的Transact-SQL编码的最大障碍。正好相反，没有真正掌握一门语言的缺点和优点—— 这些使事物具有独特性的东西—— 才是用它构建好软件的最大障碍。您只能通过学科间的交叉工作获得才能正确评估这些软件的缺点和优点。对于Transact-SQL，它的优点是面向集合的开发，基本缺点是自上到下的程序设计方式。这不意味着您使用Transact-SQL只能编写面向集合的程序，编写过程Transact-SQL代码是一种蛮干的方式。毕竟我们称之为存储过程。这只意味着您的编码风格和Transact-SQL不同，就像和编写Visual Basic的不同一样。不止Transact-SQL是这样，许多语言也是如此。许多语言具有使其具有惟一性的细微差别和习惯用法，您不会像编写Visual Basic一样编写C++。针对具体工作使用正确的工具，发挥工具的优点，避免它的缺点，不但要掌握工具本身，还应进行更一般的软件开发，这样才会对其优缺点越来越熟悉。您的目的是要成为一位高明的程序员，不止是一个存储过程专家。 我和Joe在San Francisco共进晚餐时曾说过：我仍然认为在很长一段时间内C#是程序设计的最理想语言。 Ken Henderson 2001年1月