（已有70条评价）基本信息
- 作者： (美)Stephane Faroult Peter Robson
- 译者： 温昱 靳向阳
- 出版社：电子工业出版社
- ISBN：9787121058349
- 上架时间：2008-3-28
- 出版日期：2008 年3月
- 开本：16开
- 页码：349
- 版次：1-1
- 所属分类：计算机 > 数据库 > SQL语言
编辑推荐
资深 SQL 专家 Stephane Faroult倾力打造.
《软件架构设计》作者温昱最新译作
巧妙借鉴《孙子兵法》的智慧结晶..
传授25年的SQL性能与调校经验
深入探讨九种常见查询方案及其性能...
内容简介
作译者
Stephane Faroult，经营着RoughSea公司，从事数据库咨询业务，致力于帮助客户从数据库投资中获得最佳性能。他的SQL经验开始于1983年。Oracle法国的第一个性能及调优课程就是他1987年编写的。
目录
前言
1 制定计划：为性能而设计
数据的关系视图
规范化的重要性
有值、无值、空值
限用Boolean型字段
理解子类型（Subtype）
约束应明确声明
过于灵活的危险性
历史数据的难题
设计与性能
处理流程
数据集中化（Centralizing）
系统复杂性
小结
2 发动战争：高效访问数据库
查询的识别
保持数据库连接稳定
战略优先于战术
先定义问题，再解决问题
1 制定计划：为性能而设计
数据的关系视图
规范化的重要性
有值、无值、空值
限用Boolean型字段
理解子类型（Subtype）
约束应明确声明
过于灵活的危险性
历史数据的难题
设计与性能
处理流程
数据集中化（Centralizing）
系统复杂性
小结
2 发动战争：高效访问数据库
查询的识别
保持数据库连接稳定
战略优先于战术
先定义问题，再解决问题
前言
过去，“信息技术（IT）”的名字还不如今天这般耀眼，被称为“电子数据处理”。其实，尽管当今新潮技术层出不穷，数据处理依然处于我们系统的核心地位，而且需管理的数据量的增长速度似乎比处理器的增长速度还快。今天，最重要的集团数据都被保存在数据库中，通过SQL语言来访问。SQL语言虽有缺点，但非常流行，它从1980年代早期开始被广泛接受，随后就所向无敌了。.
如今，年轻开发者在接受面试时，没有谁不宣称自己能熟练应用SQL的。SQL作为数据库访问语言，已成为任何基础IT课程的必备部分。开发者宣传自己熟练掌握SQL，其实前提是“熟练掌握”的定义是“能够获得功能上正确的结果”。然而，全世界的企业如今都面临数据量的爆炸式增长，所以仅做到“功能正确”是不够的，还必须足够快，所以数据库性能成了许多公司头疼的问题。有趣的是，尽管每个人都认可性能问题源自代码，但普遍接受的事实则是开发者的首要关注点应该是功能正确。人们认为：为了便于维护，代码中的数据库访问部分应该尽量简单；“拙劣的SQL”应该交给资深的DBA去摆弄，他们还会调整几个“有魔力”的数据库参数，于是速度就快了——如果数据库还不够快，似乎就该升级硬件了。
往往就是这样，那些所谓的“常识”和“可靠方法”最终却是极端有害的。先写低效的代码、后由专家调优，这种做法实际上是自找麻烦。本书认为，首先要关注性能的就是开发者，而且SQL问题绝不仅仅只包含正确编写几个查询这么简单。开发者角度看到的性能问题和DBA从调优角度看到的大相径庭。对DBA而言，他尽量从现有的硬件（如处理器和存储子系统）和特定版本的DBMS获得最高性能，他可能有些SQL技能并能调优一个性能极差的SQL语句。但对开发者而言，他编写的代码可能要运行5到10年，这些代码将经历一代代的硬件，以及DBMS各种重要版本升级（例如支持互联网访问、支持网格，不一而足）。所以，代码必须从一开始就快速、健全。很多开发者仅仅是“知道”SQL而已，他们没有深刻理解SQL及关系理论，实在令人遗憾。
为何写作本书
SQL书主要分为三种类型：讲授具体SQL方言的逻辑和语法的书、讲授高级技术及解决问题方法的书、专家与资深DBA所需的性能和调优的书。一方面，书籍要讲述如何写SQL代码；另一方面，要讲如何诊断和修改拙劣的SQL代码。在本书中，我不再为新手从头讲解如何写出优秀的SQL代码，而是以超越单个SQL语句的方式看待SQL代码，无疑这更加重要。
教授语言使用就够难了，那么本书是怎样讲述如何高效使用SQL语言的呢？SQL的简单性具有欺骗性，它能支持的情况组合的数目几乎是无限的。最初，我觉得SQL和国际象棋很相似，后来，我悟到发明国际象棋是为了教授战争之道。于是，每当出现SQL性能难题的时候，我都自然而然地将之视为要和一行行数据组成的军队作战。最终，我找到了向开发者传授如何有效使用数据库的方法，这就像教军官如何指挥战争。知识、技能、天赋缺一不可。天赋不能传授，只能培养。从写就了《孙子兵法》的孙子到如今的将军，绝大多数战略家都相信这一点，于是他们尽量以简单的格言或规则的方式表达沙场经验，并希望这样能指导真实的战争。我将这种方法用于战争之外的许多领域，本书借鉴了孙子兵法的方法和书的题目。许多知名IT专家冠以科学家称号，而我认为“艺术”比“科学”更能反映IT活动所需的才能、经验和创造力（注1）。很可能是由于我偏爱“艺术”的原因，“科学”派并不赞成我的观点，他们声称每个SQL问题都可通过严格分析和参考丰富的经验数据来解决。然而，我不认为这两种观点有什么不一致。明确的科学方法有助于摆脱单个具体问题的限制，毕竟，SQL开发必须考虑数据的变化，其中有很大的不确定性。某些表的数据量出乎意料地增长将会如何？同时，用户数量也倍增了，又将会如何？希望数据在线保存好几年将会如何？如此一来，运行在硬件之上的这些程序的行为是否会完全不同？架构级的选择是在赌未来，当然需要明确可靠的理论知识——但这是进一步运用艺术的先决条件。第一次世界大战联军总司令Ferdinand Foch，在1900年French Ecole Superieure de Guerre的一次演讲中说：
战争的艺术和其他艺术一样，有它的历史和原则——否则，就不能成其为艺术。
本书不是cookbook，不会列出一串问题然后给出“处方”。本书的目标重在帮助开发者（和他们的经理）提出犀利的问题。阅读和理解了本书之后，你并不是永不再写出丑陋缓慢的查询了——有时这是必须的——但希望你是故意而为之、且有充足的理由。
目标读者
本书的目标读者是：
有丰富经验的SQL数据库开发者
他们的经理
数据库占重要地位的系统的软件架构师
我希望一些DBA、尤其是数据库应用维护人员也能喜欢本书。不过，他们不是本书的主要目标读者。
本书假定
本书假定你已精通SQL语言。这里所说的“精通”不是指在你大学里学了SQL 101并拿来A+的成绩，当然也并非指你是国际公认的SQL专家，而是指你必须具有使用SQL开发数据库应用的经验、必须考虑索引、必须不把5000行的表当大表。本书的目标不是讲解连接、外连接、索引的基础知识，阅读本书过程中，如果你觉得某个SQL结构还显神秘,并影响了整段代码的理解，可先阅读几本其他SQL书。另外，我假定读者至少熟悉一种编程语言,并了解计算机程序设计的基本原则。性能已很差、用户已抱怨、你已在解决性能问题的前线，这就是本书的假定。
本书内容
我发现SQL和战争如此相像，以至于我几乎沿用了《孙子兵法》的大纲,并保持了大部分题目名称（注2）。本书分为12章，每一章包含许多原则或准则，并通过举例的方式对原则进行解释说明，这些例子大多来自于实际案例。
第1章，制定计划：为性能而设计
讨论如何设计高性能数据库
如今，年轻开发者在接受面试时，没有谁不宣称自己能熟练应用SQL的。SQL作为数据库访问语言，已成为任何基础IT课程的必备部分。开发者宣传自己熟练掌握SQL，其实前提是“熟练掌握”的定义是“能够获得功能上正确的结果”。然而，全世界的企业如今都面临数据量的爆炸式增长，所以仅做到“功能正确”是不够的，还必须足够快，所以数据库性能成了许多公司头疼的问题。有趣的是，尽管每个人都认可性能问题源自代码，但普遍接受的事实则是开发者的首要关注点应该是功能正确。人们认为：为了便于维护，代码中的数据库访问部分应该尽量简单；“拙劣的SQL”应该交给资深的DBA去摆弄，他们还会调整几个“有魔力”的数据库参数，于是速度就快了——如果数据库还不够快，似乎就该升级硬件了。
往往就是这样，那些所谓的“常识”和“可靠方法”最终却是极端有害的。先写低效的代码、后由专家调优，这种做法实际上是自找麻烦。本书认为，首先要关注性能的就是开发者，而且SQL问题绝不仅仅只包含正确编写几个查询这么简单。开发者角度看到的性能问题和DBA从调优角度看到的大相径庭。对DBA而言，他尽量从现有的硬件（如处理器和存储子系统）和特定版本的DBMS获得最高性能，他可能有些SQL技能并能调优一个性能极差的SQL语句。但对开发者而言，他编写的代码可能要运行5到10年，这些代码将经历一代代的硬件，以及DBMS各种重要版本升级（例如支持互联网访问、支持网格，不一而足）。所以，代码必须从一开始就快速、健全。很多开发者仅仅是“知道”SQL而已，他们没有深刻理解SQL及关系理论，实在令人遗憾。
为何写作本书
SQL书主要分为三种类型：讲授具体SQL方言的逻辑和语法的书、讲授高级技术及解决问题方法的书、专家与资深DBA所需的性能和调优的书。一方面，书籍要讲述如何写SQL代码；另一方面，要讲如何诊断和修改拙劣的SQL代码。在本书中，我不再为新手从头讲解如何写出优秀的SQL代码，而是以超越单个SQL语句的方式看待SQL代码，无疑这更加重要。
教授语言使用就够难了，那么本书是怎样讲述如何高效使用SQL语言的呢？SQL的简单性具有欺骗性，它能支持的情况组合的数目几乎是无限的。最初，我觉得SQL和国际象棋很相似，后来，我悟到发明国际象棋是为了教授战争之道。于是，每当出现SQL性能难题的时候，我都自然而然地将之视为要和一行行数据组成的军队作战。最终，我找到了向开发者传授如何有效使用数据库的方法，这就像教军官如何指挥战争。知识、技能、天赋缺一不可。天赋不能传授，只能培养。从写就了《孙子兵法》的孙子到如今的将军，绝大多数战略家都相信这一点，于是他们尽量以简单的格言或规则的方式表达沙场经验，并希望这样能指导真实的战争。我将这种方法用于战争之外的许多领域，本书借鉴了孙子兵法的方法和书的题目。许多知名IT专家冠以科学家称号，而我认为“艺术”比“科学”更能反映IT活动所需的才能、经验和创造力（注1）。很可能是由于我偏爱“艺术”的原因，“科学”派并不赞成我的观点，他们声称每个SQL问题都可通过严格分析和参考丰富的经验数据来解决。然而，我不认为这两种观点有什么不一致。明确的科学方法有助于摆脱单个具体问题的限制，毕竟，SQL开发必须考虑数据的变化，其中有很大的不确定性。某些表的数据量出乎意料地增长将会如何？同时，用户数量也倍增了，又将会如何？希望数据在线保存好几年将会如何？如此一来，运行在硬件之上的这些程序的行为是否会完全不同？架构级的选择是在赌未来，当然需要明确可靠的理论知识——但这是进一步运用艺术的先决条件。第一次世界大战联军总司令Ferdinand Foch，在1900年French Ecole Superieure de Guerre的一次演讲中说：
战争的艺术和其他艺术一样，有它的历史和原则——否则，就不能成其为艺术。
本书不是cookbook，不会列出一串问题然后给出“处方”。本书的目标重在帮助开发者（和他们的经理）提出犀利的问题。阅读和理解了本书之后，你并不是永不再写出丑陋缓慢的查询了——有时这是必须的——但希望你是故意而为之、且有充足的理由。
目标读者
本书的目标读者是：
有丰富经验的SQL数据库开发者
他们的经理
数据库占重要地位的系统的软件架构师
我希望一些DBA、尤其是数据库应用维护人员也能喜欢本书。不过，他们不是本书的主要目标读者。
本书假定
本书假定你已精通SQL语言。这里所说的“精通”不是指在你大学里学了SQL 101并拿来A+的成绩，当然也并非指你是国际公认的SQL专家，而是指你必须具有使用SQL开发数据库应用的经验、必须考虑索引、必须不把5000行的表当大表。本书的目标不是讲解连接、外连接、索引的基础知识，阅读本书过程中，如果你觉得某个SQL结构还显神秘,并影响了整段代码的理解，可先阅读几本其他SQL书。另外，我假定读者至少熟悉一种编程语言,并了解计算机程序设计的基本原则。性能已很差、用户已抱怨、你已在解决性能问题的前线，这就是本书的假定。
本书内容
我发现SQL和战争如此相像，以至于我几乎沿用了《孙子兵法》的大纲,并保持了大部分题目名称（注2）。本书分为12章，每一章包含许多原则或准则，并通过举例的方式对原则进行解释说明，这些例子大多来自于实际案例。
第1章，制定计划：为性能而设计
讨论如何设计高性能数据库
媒体评论
体悟战争箴言，精通SQL兵法：
在所有战争中，显示军事才华的第一步是战略规划。
——Joseph de Maistre
战争中有一些基本的原则，无视这些原则非常危险，而遵循这些原则就可能胜利。
——General Antoine-Henri de Jomini
无论谁想运筹帷幄，都要遵循罗马的战略战术：首先是速决战。
——Niccolo Machiavelli
没有人可以保证战争的胜利，只能等待它的回报。
——温斯顿·丘吉尔
在所有战争中，显示军事才华的第一步是战略规划。
——Joseph de Maistre
战争中有一些基本的原则，无视这些原则非常危险，而遵循这些原则就可能胜利。
——General Antoine-Henri de Jomini
无论谁想运筹帷幄，都要遵循罗马的战略战术：首先是速决战。
——Niccolo Machiavelli
没有人可以保证战争的胜利，只能等待它的回报。
——温斯顿·丘吉尔
