編輯推薦
SQL編程風格資料庫作為現代軟體套用的核心之一，正在發揮越來越重要的作用。很自然地，SQL在廣大程式設計師的日常工作中也成了不可或缺的技術。學會SQL並不難，但是要成為優秀的SQL程式設計師就絕非易事了。大部分程式設計師都是在學習並從事了過程化或面向對象編程之後才轉到SQL。因此往往帶有濃重的口音，而且常常缺乏自知之明。
本書中，世界級SQL專家Joe Celko針對資料庫的設計與編程提出了一系列規則和建議，內容涵蓋命名規範、代碼版式、鍵的設計、數據編碼方案、編碼風格、SQL中的思考方式等多個方面。可以作為軟體公司內部編程規範的基礎。書中講述了如何編寫標準、高效、易於維護的SQL代碼。更重要的是。還教授讀者如何像優秀的SQL程式設計師那樣思考，用查詢的思維方式來理解資料庫，從而大大改善SQL編程風格並提高SQL編程水平。
內容簡介
通過閱讀本書，讀者可以加深對SQL 思維方式的理解，改善SQL 編程風格，並編寫出可讀性強、可移植且易於維護的SQL 代碼。此外，書中的規則對於公司內部制定編程規範也具有很好的借鑑作用。
本書適合資料庫管理人員和開發人員閱讀，也可作為高等院校計算機專業師生的參考教材。
作者簡介
Joe Celko世界著名的資料庫專家，曾經擔任ANSI SQL標準委員會成員達10年之久，他也是世界上讀者數量最多的SOL圖書作者之一。他曾撰寫過一系列專欄，並通過他的新聞組支持了資料庫編程技術以及ANSI／ISO標準的發展。除本書外，他還撰寫了多部SQL經典著作，包括《SQL解惑（第2版）》（人民郵電出版社，2008）和《SOL權威指南》（即將由人民郵電出版社出版）。
圖書目錄
第1章 名稱與數據元素
1.1 名稱
1.1.1 注意名稱長度
1.1.2 在名稱中避免使用所有特殊字元
1.1.3 避免使用引號分隔標識符
1.1.4 實施大寫規則以避免大小寫區分問題
1.2 遵循ISO-11179標準命名規範
1.2.1 SQL的ISO-11179
1.2.2 抽象級別
1.2.3 避免使用描述性前綴
1.2.4 制定標準化的後綴
1.2.5 表和視圖名稱應當是遵循業界標準的、集合、類或複數名稱
1.2.6 相關名基本上也要遵循與其他名稱相同的命名規則
1.2.7 關係表名應當是常用描述術語
1.2.8 元數據模式訪問對象的名稱可以包含結構信息
1.3 命名數據元素時遇到的問題
1.3.1 避免模糊名稱
1.3.2 避免名稱在不同的地方改變
1.3.3 不要使用專有暴露的物理定位符
第2章 字型、標點和間距
2.1 版式與代碼
2.1.1 名稱中只使用大小寫字母、數字和下劃線
2.1.2 列名、參數和變數等標量小寫
2.1.3 模式對象名首字母大寫
2.1.4 保留字大寫
2.1.5 避免使用駝峰命名法
2.2 單詞間距
2.3 遵循規範標點規則
2.4 使用完全保留字
2.5 如果在使用的SQL產品中有標準保留字，就不要使用專有保留字
2.6 如果有標準語句，就不要使用專有語句
2.7 疏排版面的隔空白道和垂直間距
2.8 縮進
2.9 使用行間距將語句分組
第3章 數據定義語言
3.1 將默認值放到合適的地方
3.2 默認值的類型應當與列的類型相同
3.3 不要使用專有數據類型
3.4 將PRIMARY KEY聲明放在CREATE TABLE語句的開頭
3.5 將列按照邏輯順序排列並按照邏輯組聚合
3.6 將參考約束和操作在數據類型下面縮進
3.7 在產品代碼中為約束命名
3.8 將CHECK()約束放在所檢查的內容附近
3.8.1 對數值考慮使用範圍約束
3.8.2 對於字元值考慮使用LIKE和SIMILAR TO約束
3.8.3 時間值是有長短的
3.8.4 避免使用REAL和FLOAT數據類型
3.9 將多列約束儘可能靠近這些列
3.10 將表級別的CHECK()約束放到表聲明的最後
3.11 對多表約束使用CREATEassertion
3.12 使CHECK()約束的目的唯一
3.13 每個表都必須有鍵才能稱為表
3.13.1 自動編號不是關係型鍵
3.13.2 檔案不是表
3.13.3 鍵的屬性
3.14 不要分割屬性
3.14.1 分割為多個表
3.14.2 分割為多個列
3.14.3 分割為多個行
3.15 不要對RDBMS使用面向對象的設計
3.15.1 表不是對象實例
3.15.2 對RDBMS不要使用EAV設計
第4章 尺度與測量
4.1 測度論
4.1.1 範圍與顆粒度
4.1.2 範圍
4.1.3 顆粒度、準確度和精度
4.2 尺度類型
4.2.1 名義尺度
4.2.2 種類尺度
4.2.3 絕對尺度
4.2.4 順序尺度
4.2.5 級別尺度
4.2.6 間距尺度
4.2.7 比例尺度
4.3 使用尺度
4.4 尺度轉換
4.5導出單位
4.6 標點與標準單位
4.7 在資料庫中使用尺度的一般準則
第5章 數據編碼方案
5.1 不好的編碼方案
5.2 編碼方案類型
5.2.1 枚舉編碼
5.2.2 測量編碼
5.2.3 縮寫編碼
5.2.4 算法編碼
5.2.5 層次編碼
5.2.6 向量編碼
5.2.7 拼接編碼
5.3 設計編碼方案的一般準則
5.3.1 現有的編碼標準
5.3.2 允許擴展
5.3.3 使用顯式的丟失值避免NULL
5.3.4 為終端用戶轉換編碼
5.3.5 在資料庫中保存編碼
5.4 多字元集
第6章 編碼選擇
6.1 選擇標準構造，不要選擇專有構造
6.1.1 使用標準OUTER JOIN語法
6.1.2 中綴INNER JOIN和CORSS JOIN語法是可選的，但是很好用
6.1.3 使用ISO時間語法
6.1.4 使用標準和可移植的函式
6.2 選擇緊湊格式，不要選擇鬆散格式
6.2.1 避免使用多餘的括弧
6.2.2 使用CASE系列表達式
6.2.3 避免使用冗餘表達式
6.2.4 尋找緊湊格式
6.3 使用注釋
6.3.1 存儲過程
6.3.2 控制語句注釋
6.3.3 對子句的注釋
6.4 避免最佳化器提示
6.5 觸發器的優先權不應當高於DRI操作
6.6 使用SQL存儲過程
6.7 避免在資料庫中使用用戶定義函式和擴展
6.7.1 多語言問題
6.7.2 可移植性問題
6.7.3 最佳化問題
6.8 避免使用過度的輔助索引
6.9 避免使用關聯子查詢
6.10 避免使用UNION
6.11 測試SQL
6.11.1 測試NULL所有可能的組合
6.11.2 檢查並測試所有的CHECK()約束
6.11.3 注意字元列
6.11.4 測試大小
第7章 如何使用視圖
7.1 視圖的命名規範與表一樣
7.2 視圖提供行和列級別的安全性
7.3 視圖確保了有效訪問路徑
7.4 視圖對用戶隱藏了複雜性
7.5 視圖確保了正確的數據派生
7.6 視圖將表和／或列重新命名
7.7 視圖實施複雜的完整性約束
7.8 可更新的視圖
7.8.1 WITH CHECK OPTION子句
7.8.2 INSTEAD OF觸發器
7.9 每個視圖都要有創建的原因
7.10 避免視圖的數量快速增長
7.11 將視圖與基表同步
7.12 不恰當地使用視圖
7.12.1 用於域支持的視圖
7.12.2 單個解決方案的視圖
7.12.3 不要為每個基表都創建視圖
7.13 學習使用物化的視圖
第8章 如何編寫存儲過程
8.1 大多數SQL4GL都不是用於應用程式的
8.2 基本軟體工程
8.2.1 內聚
8.2.2 耦合
8.3 使用傳統的結構化編程
8.4 避免可移植性問題
8.4.1 避免創建臨時表
8.4.2 避免使用游標
8.4.3 面向集合的構造優於過程化代碼
8.5 標量與結構化參數的對比
8.6 避免使用動態SQL
8.6.1 性能
8.6.2 SQL注入
第9章 試探法
9.1 將規格說明表達為清晰的語句
9.2 在名詞的後面加上“……的集合”
9.3 從問題語句中刪除行為動詞
9.4 仍然可以使用存根
9.5 不要擔心數據的顯示
9.6 第一次嘗試需要特別處理
9.6.1 不要捨不得扔掉你對DDL的第一次嘗試
9.6.2 保存你對DML的第一次嘗試
9.7 不要以方框和箭頭的方式思考
9.8 畫圓圈和集合圖
9.9 學習方言
9.10 假設WHERE子句是“巨型變形蟲”
9.11 使用新聞組和網際網路
第10章 以SQL的方式思考
10.1 不好的SQL編程方式與過程化語言
10.2 把列當作欄位思考
10.3 以過程化而不是說明性的方式思考
10.4 模式應該看起來像輸入格式
附錄A 資源
附錄B 參考文獻
索引
媒體評論
“Joe Celko是當今資料庫界最著名的代表之一，他已經寫了不少SQL編程的暢銷書。但是。本書非常與眾不同，它將教你如何轉變思維方式，以邏輯和說明性的方式編程。成為一流的SQL開發人員。”
——sQL-Server-Performance.corn
書摘插圖
第1章 名稱與數據元素
1.1 名稱
以前，每個程式設計師都有一套自己的命名規範。但是，他們常常都太有創造性了。我特別喜歡舉的一個例子是，有一個人使用某類主題詞作為他的COBOL段名：一段程式可能使用國家名，另外一段可能使用花卉，等等。即使就程式設計師而言，這顯然也是很奇怪的行為，但是很多程式設計師的個人命名系統只有他們自己明白，別人都無法理解。
例如，我使用的第一個FORTRAN版本只允許6個字母的名稱，所以我變得善於使用和發明6個字母的名稱。開始編程時使用弱類型或無類型語言的程式設計師們都喜歡使用匈牙利表示法（參見Leszynski和Reddick）。老的習慣很難放棄。
當軟體工程變成規範後，每個公司都制定了自己的命名規範，並使用某種數據字典實施這些規範。使用最廣泛的一套規則可能要算是由美國國防部建立的MIL STD8320.1，但它在聯邦政府之外卻從未流行起來。這與先前缺乏有效組織的體系相比，已經有了很大進步，但是每個公司都有很大的不同：有些對於名稱構造有正式的規則，而另外一些則只是將賦予數據元素的第一個名稱登記一下。
現在，我們有了ISO-11179標準，它正變得越來越普遍，是某些政府工作所需要的，並且正在被放入到數據儲存庫產品中。一些工具和大量標準化編碼方案也被放入到了這個標準中。考慮到這一點，並考慮到XML是一種標準交換格式，ISO-11179在今後將成為元數據參考的方法。
