⑴ SQL实战新手入门：交叉联接(CROSS JOIN)
交叉联接（CROSS JOIN）
最后 将介绍另外一种不同类型的联接 实际上 它的语法不允许定义行匹配的条件
SELECT
loc_bookcase
loc_shelf
loc_position_left
bk_title
FROM location CROSS JOIN books
（ row（s） affected）
这怎么可能呢？查询结果产生了 行记录？在每一个表中仅有 条记录啊！这是什么类型的联接呢？它就是交叉联接 又称为笛卡尔积 请回顾一下笛卡尔坐标系统 它由两根互为直角的轴构成 两轴交叉点的坐标为 并从 开始沿轴逐渐增加数值 笛卡尔坐标系统的一个常见的例子就是国际象棋的棋盘 它沿着轴用字母取代了数字 除此之外 两者是类似的
如果对棋盘上陪册的每一个方格进行命名 可以使用棋盘上的坐标 A A E E 等 换句话说 即将一个轴上的每一个值都与另外一个轴上的每一个值进行匹配 这就是笛卡尔积（这非常类似于将轴上的值 相乘 :A× A× 等）
CROSS JOIN对于两个表执行类似的操作 它将一个表中的每一行与另外一个表中的每一行进行配对 可以想象 CROSS JOIN的结果集通常都源携相当大 在上面的例子中 仅仅交叉联接两个表（每个表只有 行数据）就返回了 行结果 如果在查询中加入更多的表 那么结果集将芦裂宏变得更加庞大
如何建立CROSS JOIN呢？实际上无需太多的语法 使用旧式SQL语法来创建CROSS JOIN非常简单 只需要在FROM子句中列出要选取的表 无需任何JOIN条件
SELECT
loc_bookcase
loc_shelf
loc_position_left
bk_title
FROM location books
也就是说 无须使用任何JOIN关键字 只需要在FROM子句中列出要交叉联接的表即可 但是这会产生一个困境 忽略WHERE子句将创建一个笛卡尔积的查询 并且编写这样的SQL查询非常简单 然而 结果集可能会超出希望查询的数据范围 表 显示了将LIBRARY数据库中的表逐步增加到CROSS JOIN查询中时结果集数量的增长过程
表 LIBRARY数据库中的笛卡尔积
LIBRARY数据库非常小 只包含 个表 其中没有一个表超过 条记录 但使用CROSSJOIN时却产生了极大的结果集 设想一下 如果对于一个包含了几十个甚至上百个表的产品级的数据库（其中可能包含了上百万的记录）使用CROSS JOIN将会产生什么样的后果？毫无疑问 这会将数据库折磨到挂掉 并让DBA恼火不已
可以在CROSS JOIN中使用一个WHERE子句来减少返回记录的数量 例如 使用下面的查询产生一个笛卡尔积
SELECT loc_bookcase loc_shelf loc_position_left bk_title
FROM location CROSS JOIN books
WHERE bk_id =
该查询仅返回 条记录 而不是前面例子中的 条记录
幸运的是 新的SQL语法要求首先显式地声明联接的类型 这可以避免查询意外地产生不必要的笛卡尔积 新SQL语法要求必须使用CROSS JOIN关键字或者应用联接条件 对于DBA请注意以下的警告 使用旧的联接语法对数据库是有害的 很多RDBMS在它们各自的数据库中已经停止了对旧语法的支持 除非需要处理遗留的代码 否则在查询中最好不要再使用旧式语法
读者可能会感到疑惑 如果CROSS JOIN是不良的 应该避免使用的联接 那为什么还要自寻烦恼地提供CROSS JOIN关键字呢？实际上 CROSS JOIN也有合理的用途 例如 它提供了一个快速又简单的办法来产生巨量的数据集 可用于测试用途 另外一种应用场景是通过CROSS JOIN产生的数据集来选取行 这些行既无法通过INNER JOIN也无法通过OUTER JOIN来产生 例如 选取对于指定产品的销售总量为 的客户（或者在LIBRARY数据库的情形下查询在一年内没有借阅一本特定图书的客户）
CROSS JOIN是一个极为强大的工具 因此也必须谨慎地加以使用 处理巨大的数据集将消耗系统资源 在SQL中 最佳实践之一就是在查询中尽可能地对记录进行筛选 并最小化须访问的数据的数量
一个SQL查询对于可以包含多少个JOIN操作是否存在限制呢？对于预备执行计划的复杂性都存在实际的限制 更不用说执行这些复杂的计划可能会使服务器崩溃 实际的数量取决于RDBMS以及运行RDBMS的硬件环境 如果你发现联接太多的表 那么应该重新考虑你的查询方案
返回目录 SQL实战新手入门
编辑推荐
Oracle索引技术
高性能MySQL
lishixin/Article/program/SQL/201311/16467
⑵ SQL实战新手入门：关系型数据库管理系统
关系型数据库管理系统
本书是讲述SQL的 它是一种关系型数据库或者关系型数据库管理系统（RDBMS）的语言 自从Codd博士在 世纪 年代奠定关系型数据库的理论基础以来 已经产生了相当多的关系型数据库实现 一些新的关系型数据库实现也不断出现
很多人将DB 视为所有数据库的鼻祖 IBM的研究员Edgar Frank Codd博士在 年的一份IBM的研究报告中发表他的论文 Derivability Rendancy and Consistency of Relations Stored inLarge Data Banks 时 给这种数据库理论定义了一个非常恰当的术语 关系型 关系型数据库被其他两种技术竞争 一种是Honeywell Information Systems在 年销售的Multics RelationalData Store 另一种是密歇根大学从 年起作为实验性设计的Micro DBMS（它开创了Codd博士两年之后提出的规范化理论） Micro DBMS的最后一个产品已经于 年退役 这两种技术演变成了 年发布的Oracle V 商业数据库 在通往RDBMS的道路上 包含了很多其他公司的产品所树立的里程碑（当然偶尔也有墓碑） 这些产品包括 IBM PRTV（ ） IBM SQL/DS（ ） QBE（ ） Informix（ ） Sybase（ ） Teradata（ ） Ingres 一个给其他很多成功的系统带来灵感的开源项目 例如PostgreSQL（ ） Nonstop SQL（ ）和MicrosoftSQL Server（ ）等 这些系统使用了原始SQL的不同方言 SEQUEL QUEL Informix SQL等 直到 年 人数培们才第一次试图为SQL语言制定标准 毫无疑问 各个厂商关于SQL语言的战争仍在继续
当前的RDBMS市场已经被几个重量级的专有关系型数据库瓜分 Oracle（ %） IBM（ %）和Microsoft（ %） 更小的专有数据库系统Teradata和Sybase 每种不到 %的市场份额 其他数据库厂商 包括开源数据库轿毕旁 大约占有 %的市场份额
对于大型企业来说 选择一个数据库产品作为应用程序的基础并不是一个简单的任务 这不仅仅是因为数据库系统软件需要花费好几万美元的许可证费用 几十万美金的维护和技术支持费 而且在于与其他软件 硬件和人力资源投资相比 数据库软件的投资还是一个决定整个企业架构的关键要素 尽管近年来从一个RDBMS迁移到另一个RDBMS变得更加容易 但考虑选择哪一种数据库依然会给CFO带来噩梦
IBM DB LUW
从带有MVS系列操作系统的大型机到z/OS 以及闭橡后来的UNIX和Windows系统 IBM在RDBMS领域都是一个长期的领跑者 IBM数据库的当前版本是IBM DB LUW（Linux UNIX和Windows）
IBM DB 在事务处理速度上保持了绝对领先的记录（更多信息请参见第 章） 它具有多个不同的版本 从Advanced Server Enterprise版本到免费的DB Express C版本（尽管功能上有限制） 免费的DB Express C版本可用于运行本书中的示例
直到DB 的 版本 依然遵循ANSI/ISO SQL Entry标准（请参考本章后面的内容）并支持由其他标准化组织制定的一些高级功能 例如Open Geospatial Consortium（开放地理信息联盟） JDBC X/Open XA 它还包含了最新SQL: 标准的部分功能 除了自己内置的过程化扩展语言SQL PL之外 它还支持使用Oracle的PL/SQL语言 Java语言 甚至Microsoft的 NET家族的语言来创建存储过程（更多内容请参见第 章）
Oracle
Oracle数据库可以追溯到 年第一次发布的Oracle V 开始时用于VAX/VMS系统 并于 年支持UNIX系统 经过多年发展 对于SQL标准定义的绝大多数功能 Oracle数据库都添加了相应的支持 在最新发布的Oracle g版本中功能支持达到了极致 它声称遵循最新SQL: 标准的很多功能
在高性能事务处理的标杆上 Oracle占据了第二名的位置 它是企业生态系统的核心 Oracle是一个安全的 健壮的 可伸缩的 高性能的数据库系统 它统治UNIX市场长达数十年 除了对SQL标准的支持之外 Oracle还提供了一种内置的过程化语言PL/SQL（关于过程化扩展的更多内容 请参见第 章） 另外它还支持通用的程序设计语言 例如Java
在写作本书之时 Oracle的最新版本是Oracle g 只有Oracle g有免费的速成版 该版本在数据存储的容量和RDBMS能够利用的处理器（CPU）数量上存在一定的限制 速成版完全支持本书所讨论的所有SQL功能
Microsoft SQL Server
SQL Server来源于Microsoft Ashton Tate和Sybase合作的结果 开始的目标是改写已有的 仅适用于UNIX的Sybase SQL Server数据库 使之适用于新的IBM操作系统OS/ Ashton Tate随后退出了这一合作 IBM OS/ 操作系统也逐渐被人淡忘 Microsoft和Sybase为了分享成果 开始小心地避免触犯彼此 Microsoft致力于发展并支持Windows和OS/ 系统上的SQL Server 而Sybase则致力于UNIX平台 尽管在SQL Server的核心技术上Microsoft依然采用了相当多的Sybase技术 但双方的合作关系于 年正式结束 Microsoft于 年发布了Microsoft SQLServer 它消除了Sybase余留的痕迹 为世界（Windows系统的世界）带来了一个完全崭新的RDBMS系统 时至今日 Microsoft占据了RDBMS大约 %的市场份额 而在Windows系统上它占据了至高无上的位置
在写作本书之时 最新版本是Microsoft SQL Server Release Microsoft还提供了一个免费但有限制的Express版本 它支持本书所介绍的全部SQL功能
Microsoft Access
Microsoft Access也被称为Microsoft Office Access 它是一个桌面型关系数据库（相对来说是关系型的） Microsoft Access的设计目标是成为一个集成的解决方案 结合关系型数据库引擎的要素和应用程序开发的基础结构（配套有内置的程序设计语言和程序设计模型） 并作为一个报表平台 与本书中讨论的其他RDBMS不同的是 Microsoft Access是一个基于文件的数据库 因此它在性能和可伸缩性方面都存在固有的局限 例如 虽然最新版本的Access理论上允许最多 个并发用户 但在实践中超过 多个用户就会减慢Access的性能 Access仅支持SQL标准的一个子集 它提供了许多仅在Access环境中有效的功能
Access提供的功能之一就是从远程数据库链接表的能力 该功能使Access可以作为应用程序
的前端 访问任何与ODBC/OLEDB兼容的数据库
PostgreSQL
PostgreSQL是从美国加州伯克利大学的Michael Stonebraker所领导的一个项目演变而来的 Michael Stonebraker是关系型数据库理论的先驱 在最初的Ingres项目以及其继任者PostgreSQL中采用的那些原则也以各种方式被其他RDBMS产品采用 例如Sybase Informix EnterpriseDB和Greenplum
PostgreSQL的第一个版本发布于 年 之后第二年以 版本的名义发布 并保留了一个由一组专门的开发人员维护的开源项目 PostgreSQL具有很多个商业版本 最着名的是EnterpriseDB 一个私人公司为该产品提供企业支持（以及大量专有的管理工具） 在一些苛刻的企业级应用环境中 很多高端客户（例如Sony和Vonage）都采用了开源的RDBMS 这充分证明了EnterpriseDB的性能
在对SQL标准的支持方面 PostgreSQL可以说是最接近SQL标准的 另外它还提供了很多在其他数据库中所没有的功能 与它的开源伙伴（例如MySQL）不同 PostgreSQL从一开始就提供了参照完整性和事务支持 PostgreSQL内置了对PL/pgSQL过程化扩展语言的支持 另外实际上还具有适配其他任何语言来实现过程化扩展的功能
MySQL
MySQL最先是由Michael Widenius和David Axmark于 年开发的 并于 年发布了第一个版本 MySQL最初定位为一个轻量级的快速数据库 用于作为数据驱动型网站的后台数据库 尽管MySQL缺乏更加成熟的RDBMS产品所具有的许多功能 但在提供信息服务的速度上非常快 对于很多场合来说都已经 足够好 （为了达到真正的快速 MySQL避开了参照完整性约束和事务支持 更多内容请参见第 章和第 章） 另外 MySQL有着无法抗拒的价格 它是免费的 因此 在中小规模的用户群中 MySQL成为最流行的关系型数据库 在数据库产品的市场上 很多其他的免费产品在功能上都有所缺乏或者带有近乎商业炒作的宣传 数据库产品的巨人 Oracle IBM Microsoft和Sybase在那时也都没有提供各自RDBMS产品的免费速成版 在 年 Sun Microsystems公司收购了MySQL 随后Sun公司又被Oracle收购
目前 Oracle提供了一个带有商业支持的MySQL版本和一个Community Edition版本 伴随着这一收购 出现了大量分支版本 例如MariaDB和 Percona Server 它们在通用公共许可证（General PublicLicense GPL）下继续保持免费状态 GPL是一种限制最小的开源许可证
MySQL的最新版本是 MySQL 也已经指日可待 它是多平台的（Linux/UNIX/Windows） 并且支持SQL: 的绝大多数功能 其中一些功能依赖于选定的配置选项（例如 存储引擎）
存储引擎选项是MySQL独一无二的特性 它允许采用不同的方式处理不同的表类型 每一种引擎都有独特的功能和一定的限制（例如事务支持 聚集索引 存储限制等） 可以采用不同的存储引擎选项来创建MySQL数据库中的表 默认使用的是MyISAM引擎
HSQLDB和OpenOffice BASE
超结构化查询语言数据库（Hyper Structured Query Language Database HSQLDB）是一个用Java程序设计语言实现的关系型数据库管理系统 它是伯克利软件发行（BSD）许可证（这个许可证相当宽松）下的一个开源数据库
HSQLDB是OpenOffice BASE自带的默认RDBMS引擎 OpenOffice BASE是一个桌面型数据库 被定位于和Microsoft Access进行市场竞争 OpenOffice BASE也是一个关系型数据库 它健壮 功能丰富且相当快速 支持多种平台 包括Linux 各种版本的UNIX和Microsoft Windows OpenOffice BASE声称几乎完全遵循SQL: 标准 该标准包含了本书所讨论的绝大多数SQL子集
改写过的HSQLDB可以作为OpenOffice 套件组件BADE的一个嵌入的后端 并从 版本开始成为OpenOffice 套件中的一部分 与Microsoft Access类似 假如有适当的驱动程序的话 OpenOffice BASE可以连接到多种不同的RDBMS 在OpenOffice BASE产品中 已经包含了大量可用的Java Database Connectivity（JDBC）和ODBC（Open Database Connectivity）驱动程序
随着Oracle收购了OpenOffice 而其在Oracle的资助下作为开源项目的状态并不明确 OpenOffice 社区决定启动一个名为LibreOffice的新项目 意图在原来的BSD许可证的授权下将LibreOffice作为一个免费软件 实现OpenOffice的所有功能
关系型数据库并不是数据库领域中唯一的主角 一些似乎已经被关系型数据库理论打败的旧技术在更快和更便宜的硬件以及软件创新的帮助下卷土重来 对更高性能和更容易创建应用程序的需求催生了对列式数据库（columnar database）和面向对象数据库 使 将所有数据放在一个桶中 方法可行的框架 特定领域扩展（例如测地数据管理或多媒体）以及各种数据访问机制的研究 第 章将讨论这些话题
返回目录 SQL实战新手入门
编辑推荐
Oracle索引技术
高性能MySQL
lishixin/Article/program/SQL/201311/16492
⑶ SQL实战新手入门：获取数据-SELECT语句（1）
获取数据 SELECT语句（ ）
现在MYLIBRARY表中已经有了数据 可以对该表执行查询 以精确地查找所具有的图书 SELECT语句用于从表中获取数据 要使用SELECT语句获取数据 只需要告诉它表名和列名
SELECT all_my_books FROM myLibrary;
尽管该查询可以产生一个图书信息的列表 但它还不是特别有用 该图书信息是一大堆的数据 将其存储在一个关系型数据库中的唯一好处就是可以轻而易举地重新获取或打印这些信息 如果要搜索数据呢？要查找是否有某一本特定的图书 必须获取所有的记录 然后人工地逐一遍历每一条记录！这并不是我们期望从一个复杂的RDBMS软件获得的结果
需要采用某种办法来标识存储在表中的记录的特殊关键词 例如图书名称或ISBN号 对于该问题 一个标准的程序设计方式的答案就是对记录进行解析 将记录切分为多个片段 并在一个循环中遍历查找特定的目标词汇 对于表中的每一条记录重复执行这一过程 如果没有特定于厂商的过程化扩展 SQL无法执行任何类似的操作 这种方式违背了SQL语言是一种声明性语言的本质 并要求深刻地理解数据结构 下面让我们再看一看输入到MYLIBRARY表中的第一条记录
SQL Bible by Alex Kriegel Boris M Trukhnov Paperback: pages
Publisher: Wiley; edition （April ） Language: English
ISBN :
如何才能将记录切分为不同的信息片段呢？每一个片段之间的标记是什么呢？如何区分图书的名称和作者呢？如果使用空格符作为分隔符 那么SQL和Bible将被切分为不同的片段 但在逻辑上SQL和Bible属于同一个信息片段 如何才能知道by是一个介词 而不是作者姓名中的一部分？解决的办法来自SQL结构化的本性 毕竟SQL是一种结构化的查询语言 要解决这一问题 需要更多的列来存储不同片段的信息 将一个笨重的字符串拆分为多个语义上有着密切联系的数据片段就可以独立地标识每一个数据片段 因为每一个片段都成为一个单独的列 回到CREATE TABLE语句（首先删除现有的表）
DROP TABLE myLibrary;
根据上面的讨论创建一个新表
CREATE TABLE myLibrary
（
title VARCHAR（ ）
author VARCHAR（ ）
author VARCHAR（ ）
publisher VARCHAR（ ）
pages INTEGER
publish_date VARCHAR（ ）
i *** n VARCHAR（ ）
book_language VARCHAR（ ）
）
在新表的结构中 将原来的单个列拆分为 个列 另外还可以添加第 个列 将作者的名和姓拆分到两个单独的列中（这就是将在第 章中讨论的数据建模过程） 就目前而言 除了将PAGES列的数据类型设置为INTEGER类型以表示图书包含多少页之外 对于其他所有的列都使用了相同的数据类型 并缩短了每一个列中所能包含的字符数量 本章后面将进一步解释将PAGES列设置为INTEGER类型的原因 读者或许还会考虑到修改PUBLISH_DATE列的数据类型 通常情况下 日期数据的行为与字符数据不同 DBMS提供了专门用于日期和时间的数据类型
现在 无须将所有的数据都保存在同一个桶中 对于各个列的数据类型可以有更多的选择 可以将不同的列定义为不同的数据类型 当插入或更新各个列中的数据（本章后面将对此进行介绍）时 建议不要将数据类型搞混
本章后面还将重新审视数据类型 第 章也将详细地介绍数据类型
读者可能已经注意到 在新的MYLIBRARY表中有两个作者列 这是为了适应一本图书有两个作者的情形 这也提出了另外一个问题 当一本图书只有一个作者或者一本图书有 个作者时 该如何处理呢？该问题将在第 章和第 章的数据建模小节中进行深入的探讨 这里 读者只需要注意对于未使用的列将自动使用默认值进行填充 如果读者发现经常需要在表中添加新的列 那么最好花时间阅读一下关于数据库规范化方面的内容（请参见第 章）
接下来将向新表中插入数据 这一步骤与之前介绍的插入操作完全相同 唯一的差别在于VALUES列表变得更长 因为原来只包含一个列 而现在包含了 个列 在VALUES列表中 除了PAGES列的值之外 所提供的所有其他数据都必须用单引号括起来 引号表明了这些数据是字符数据 没有引号则表示数值数据
INSERT INTO myLibrary VALUES （
SQL Bible
Alex Kriegel
Boris M Trukhnov
Wiley
April
English ）
返回目录 SQL实战新手入门
编辑推荐
Oracle索引技术
高性能MySQL
lishixin/Article/program/SQL/201311/16484
⑷ SQL实战新手入门：SQL标准
SQL标准
为了在各个数据库厂商之间取得更大的统一性 美国国家标准学会（American NationalStandards Institute ANSI）段团祥于 年发布了第一个SQL标准 并于 年发布了第二个版本 该版本已经被广泛地采用 ANSI在 年更新了SQL标准的版本 即SQL 和SQL 并于 年再次更新为SQL 和SQL 标准 在每一次更新中 ANSI都在SQL中或悔添加了新特性 并在语言中集成了新的命令和功能
对于各种数据库产品 ANSI标准规范化了很多SQL行为和语法结构 随着开源数据库产品（例如MySQL mSQL和PostgreSQL）日渐流行并由虚拟团队而不是大握搏型公司开发 这些标准变得更加重要
现在 SQL标准由ANSI和国际标准化组织（International Standards Organization ISO）作为ISO/IEC 标准维护 最新发布的SQL标准是SQL: 下一版本的发布工作已经在进行之中 它将包含RDBMS在收集或分发数据方式上的新发展
返回目录 SQL实战新手入门
编辑推荐
Oracle索引技术
高性能MySQL
lishixin/Article/program/SQL/201311/16490