Effective SQL

本书结合SQL实践与实际案例，整合了实用的解决方案与洞见，可帮助大家解决复杂的问题，设计出能简化数据管理的数据库。作者拥有担任世界很好数据库顾问与讲师的丰富经验，在本书中归纳了编写高质量SQL语句的61个具体方法，并提供不同SQL版本的差异详情，无论你使用何种SQL版本都能从中获益。书中提供了大量清晰、务实的解释，以及专家的建议与大量实用的代码。本书除了介绍语法之外，还会讨论数据库设计的佳实践、层次结构管理与元数据等议题。若你对SQL已经有基本的认识，本书将能帮助你成为解决SQL问题的专家。书中内容涵盖各种SQL版本：IBMDB2、MicrosoftAccess、MicrosoftSQLServer、MySQL、OracleDatabase与PostgreSQL。

约翰·L.维卡斯,是一位拥有超过45年工作经验的数据库顾问。自1993年成立公司以来，他为各种企业提供Access与SQL Server咨询服务。任职于Applied Data Research期间，John领导着研究、开发与支持IBM主机数据库产品的专家团队。他写过多本关于数据库的书籍，并是畅销书《SQL Queries for MereMortals》第3版的作者。

本书赞誉
译者序
序
前言
致谢
关于作者
关于技术编辑
第1章数据模型设计1
第1条：确保所有表都有主键1
第2条：避免存储冗余数据4
第3条：消除重复数据组7
第4条：每列只存储一个属性9
第5条：理解为什么存储计算列通常有害无益13
第6条：定义外键以确保引用完整性16
第7条：确保表间关系的合理性19
第8条：当第三范式不够时，采用更多范式22
第9条：非规范化数据仓库27
第2章可编程性与索引设计30
第10条：创建索引时空值的影响30
第11条：创建索引时谨慎考虑以最小化索引和数据扫描35
第12条：索引不只是过滤37
第13条：不要过度使用触发器41
第14条：使用过滤索引包含或排除数据子集45
第15条：使用声明式约束替代编码校验47
第16条：了解数据库使用的SQL方言并编写相应的代码48
第17条：了解何时在索引中使用计算结果51
第3章当你不能改变设计时55
第18条：使用视图来简化不能更改的内容55
第19条：使用ETL将非关系数据转换为有用的信息60
第20条：创建汇总表并维护64
第21条：使用UNION语句将非规范化数据列转行66
第4章过滤与查找数据72
第22条：了解关系代数及其如何在SQL中实现72
第23条：查找不匹配或缺失的记录78
第24条：了解何时使用CASE解决问题79
第25条：了解解决多条件查询的技术83
第26条：如需完美匹配，先对数据进行除操作88
第27条：如何按时间范围正确地过滤日期和时间的列91
第28条：书写可参数化搜索的查询以确保引擎使用索引94
第29条：正确地定义“左”连接的“右”侧97
第5章聚合100
第30条：理解GROUPBY的工作原理100
第31条：简化GROUPBY子句106
第32条：利用GROUPBY或HAVING解决复杂的问题109
第33条：避免使用GROUPBY来查找最大值或最小值113
第34条：使用OUTERJOIN时避免获取错误的COUNT()117
第35条：测试HAVINGCOUNT(x)<某数时包含零值记录121
第36条：使用DISTINCT获取不重复的计数123
第37条：知道如何使用窗口函数126
第38条：创建行号与排名129
第39条：创建可移动聚合函数131
第6章子查询136
第40条：了解在何处使用子查询136
第41条：了解关联和非关联子查询的差异140
第42条：尽可能使用公共表表达式而不是子查询145
第43条：使用连接而非子查询创建更高效的查询151
第7章获取与分析元数据154
第44条：了解如何使用系统的查询分析器154
第45条：学习获取数据库的元数据164
第46条：理解执行计划的工作原理168
第8章笛卡儿积175
第47条：生成两张表所有行的组合并标示一张表中间接关联另一张表的列175
第48条：理解如何以等分量排名177
第49条：知道如何对表中的行配对181
第50条：理解如何列出类别与前三偏好185
第9章计数表189
第51条：根据计数表内定义的参数生成空行189
第52条：使用计数表和窗口函数生成序列193
第53条：根据计数表内定义的范围生成行196
第54条：根据计数表定义的值范围转换某个表中的值199
第55条：使用日期表简化日期计算205
第56条：创建在某个范围内所有日期的日程表209
第57条：使用计数表行转列212
第10章层次数据建模217
第58条：从邻接列表模型开始218
第59条：对不常更新的数据使用嵌套集以提升查询性能220
第60条：使用存储路径简化设置与搜索222
第61条：使用祖先遍历闭包做复杂搜索224
附录日期与时间类型、运算符和函数228

Preface  前    言结构化查询语言（Structured Query Language）简称SQL，是与大多数数据库系统通信的标准语言。如果你正在阅读本书并希望从数据库系统中获取信息，那么就需要使用SQL。    本书面向从事SQL工作的开发人员和初级数据库管理员（DBA），适合对SQL的基本语法比较熟悉并且希望再获得一些有用的技巧以便更高效地使用SQL语言的人。而且我们发现，当从计算机编程惯用的基于过程的方式转变为基于集合的方式来解决问题时，所需的思维方式是截然不同的。    关系数据库管理系统（RDBMS）是一种软件应用程序，用于创建、维护、修改和操作关系数据库。许多关系数据库系统也提供了用于操作数据库中数据的客户端工具。关系数据库系统自出现以来一直在不断发展，并随着硬件技术和操作系统环境的进步变得更加完善和强大。    SQL简史IBM研究员Edgar F. Codd博士（1923—2003）在1969年首次提出了关系数据库模型。他在20世纪60年代后期研究了处理大量数据的新方法，并开始思考如何应用数学原理解决遇到的各种问题。    自1970年Codd博士向世界提出了关系数据库模型之后，许多组织（如大学和研究实验室）开始致力于开发一种语言，用作支持关系数据库的基础。20世纪70年代中期几种不同的语言出现，其中一个正是来自位于加利福尼亚州圣何塞的IBM圣特雷莎研究实验室的努力。    20世纪70年代初，IBM启动了一个名为System/R的重大科研项目，旨在证明关系模型的可行性，并希望在设计和实现关系数据库方面获得一些经验。1974～1975年，他们的初次实验获得成功，创建了一个关系数据库的迷你原型。    在开发关系数据库的同时，研究人员也在努力定义数据库语言。1974年，Donald Chamberlin博士和他的同事发明了结构化英语查询语言（Structured English Query Language，SEQUEL），这门语言允许用户使用清晰易懂的英语句子操作关系数据库。原型数据库SEQUEL-XRM的初步成功，激励着Chamberlin和他的同事，他们决定继续研究。1976～1977年，他们把语言名称从SEQUEL修改为SEQUEL/2，但是不巧，SEQUEL缩写已经被别人使用了，出于法律原因，他们不得不将SEQUEL更名为SQL（结构化查询语言或SQL查询语言）。时至今日，虽然大家已经广泛接受了官方发音“ess-cue-el”，但是许多人还是将SQL读作“sequel”。    虽然IBM的System/R项目与SQL语言证明关系数据库是可行的，但是由于当时的硬件技术水平太低，这款产品并没有商用。    1977年，加利福尼亚州门罗公园的一群工程师创办了Relational Software公司，他们开发了一套基于SQL的关系数据库产品并命名为Oracle。1979年，Relational Software公司发布了这款产品，使之成为第一个商业化的关系数据库产品。Oracle的一大优势是能运行在Digital的VAX小型机上，而不是昂贵的IBM大型机。Relational Software公司此后更名为Oracle公司，成为RDBMS软件领域领先的厂商之一。    大约在同一时间，来自加利福尼亚大学伯克利分校计算机实验室的Michael Stonebraker、Eugene Wong和其他几位教授也在研究关系数据库技术。他们也开发了一个关系数据库的原型，命名为Ingres。Ingres使用一种称为查询语言（QUEL）的数据库语言，它比SQL结构更为清晰，而且使用了更少的类似英语的词句。但是，很明显当时SQL正在慢慢变成数据库标准语言，所以Ingres最终改为基于SQL的关系数据库。1980年，这几位教授离开伯克利，成立了Relational Technology公司。1981年，他们发布了Ingres的第一个商业版本。Relational Technology公司之后经历了几次变革。Ingres之前为Computer Associates International公司所有，现在属于Actian公司，但不管怎么样，Ingres仍然是行业数一数二的数据库产品。    1981年，IBM也宣布开发自己的关系数据库，名为SQL/DataSys（SQL / DS），并于1982年发布。1983年，IBM公司推出了一种名为Database 2（DB2）的新型关系数据库产品，它可以在安装IBM的主流MVS操作系统的IBM大型机上运行。1985年第一次发布之后，DB2就成为IBM首屈一指的关系数据库，其技术已经融入IBM整个产品线中。    随着数据库语言的不断发展，语言标准化的想法在数据库社区中呼声渐长。但是，由谁来制定标准，或者应该参照哪个方言来制定一直没有达成共识，所以每个开发商还在不断开发与改进他们自己的数据库产品，并希望有朝一日自己的数据库方言能够成为行业标准。    许多开发商都会根据用户的反馈和需求在自己的数据库方言中增加新的元素，从而形成了早期非正规的标准。相对现在的标准来说它只能算是很小的一部分，因为它只包含各种SQL方言中相似的部分。然而，正是这一小部分规范（尽管不是很完善）为数据库用户提供了一套权威的评判标准，通过这些标准可以判断市场上的各种数据库，并且用户可以在不同数据库间切换。    1982年，为了满足关系数据库语言标准化日益增长的需求，美国国家标准协会（ANSI）委托旗下X3组织数据库技术委员会X3H2制定一个标准。一番周折之后（包括对SQL的大量改进），委员会才意识到新的标准与市面上主要的SQL方言不兼容，对SQL的修改也并没有带来显著提