⑴ 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