《SQL樣式指南 SQL Style Guide》由會(huì)員分享,可在線閱讀,更多相關(guān)《SQL樣式指南 SQL Style Guide(11頁(yè)珍藏版)》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。
1、SQL樣式指南 · SQL Style Guide
Overview 綜述
你可以直接使用這些指導(dǎo)方針,或者fork后創(chuàng)建自己的版本——最重要的是選擇一套方針并嚴(yán)格遵守它。歡迎通過(guò)提交issue或pull request來(lái)提交建議或修復(fù)bug。
為了讓閱讀了Joe Celko的《SQL ProgrammingStyle》的團(tuán)隊(duì)能更容易采用這套規(guī)則, 這套原則被設(shè)計(jì)成與該書的兼容的形式。該指南在某些領(lǐng)域嚴(yán)格一些,在另一些領(lǐng)域松懈一些。 當(dāng)然該指南比Celko的書更簡(jiǎn)潔一些,因?yàn)镃elko的書包含了一些趣聞和每一條原則后的理由。
將該文檔的Markdown format格式添加
2、到項(xiàng)目代碼庫(kù)中或?qū)⒃擁?yè)面的鏈接發(fā)送給所有項(xiàng)目的參與者要比傳閱實(shí)體書容易得多。
Simon Holywell所著的《SQL樣式指南》以署名-相同方式共享 4.0 國(guó)際協(xié)議發(fā)布,改編自sqlstyle.guide。
General 一般原則
Do 應(yīng)該做的事情
· 使用一致的、敘述性的名稱。
· 靈活使用空格和縮進(jìn)來(lái)增強(qiáng)可讀性。
· 存儲(chǔ)符合ISO-8601標(biāo)準(zhǔn)的日期格式(YYYY-MM-DD HH:MM:SS.SSSSS)。
· 最好使用標(biāo)準(zhǔn)SQL函數(shù)而不是特定供應(yīng)商的函數(shù)以提高可移植性。
· 保證代碼簡(jiǎn)潔明了并消除多余的SQL——比如非必要的引號(hào)或括號(hào),或者可以推導(dǎo)出的
3、多余WHERE語(yǔ)句。
· 必要時(shí)在SQL代碼中加入注釋。優(yōu)先使用C語(yǔ)言式的以/*開始以*/結(jié)束的塊注釋,或使用以--開始的行注釋。
Avoid 應(yīng)避免的事情
· 駝峰命名法——它不適合快速掃描。
· 描述性的前綴或匈牙利命名法比如sp_或tbl。
· 復(fù)數(shù)形式——盡量使用更自然的集合術(shù)語(yǔ)。比如,用“staff”替代“employees”,或用“people”替代“individuals”。
· 需要引用號(hào)的標(biāo)識(shí)符——如果你必須使用這樣的標(biāo)識(shí)符,最好堅(jiān)持用SQL92的雙引號(hào)來(lái)提高可移植性。
· 面向?qū)ο缶幊痰脑瓌t不該應(yīng)用到結(jié)構(gòu)化查詢語(yǔ)言或數(shù)據(jù)庫(kù)結(jié)構(gòu)上。
Namin
4、g conventions 命名慣例
General 一般原則
· 保證名字獨(dú)一無(wú)二且不是保留字。
· 保證名字長(zhǎng)度不超過(guò)30個(gè)字節(jié)。
· 名字要以字母開頭,不能以下劃線結(jié)尾。
· 只在名字中使用字母、數(shù)字和下劃線。
· 不要在名字中出現(xiàn)連續(xù)下劃線——這樣很難辨認(rèn)。
· 在名字中需要空格的地方用下劃線代替。
· 盡量避免使用縮寫詞。使用時(shí)一定確定這個(gè)縮寫簡(jiǎn)明易懂。
Tables 表名
· 用集群名稱,或在不那么理想的情況下,復(fù)數(shù)形式。如staff和employees。
· 不要使用類似tbl或其他的描述性的前綴或匈牙利命名法。
· 表不應(yīng)該同它的列同名,
5、反之亦然。
· 盡量避免連接兩個(gè)表的名字作為關(guān)系表(relationship table)的名字。與其使用cars_mechanics做表名不如使用services。
Columns 列名
· 總是使用單數(shù)形式。
· 避免直接使用id做表的主標(biāo)識(shí)符。
· 避免列名同表名同名,反之亦然。
· 總是使用小寫字母,除非是特殊情況,如專有名詞。
Aliasing or correlations 別名與關(guān)聯(lián)名
· 應(yīng)該與它們別名的對(duì)象或與它們代表的表達(dá)式相關(guān)聯(lián)。
· 一般來(lái)說(shuō),關(guān)聯(lián)名應(yīng)該是對(duì)象名的第一個(gè)字母。
· 如果已經(jīng)有相同的關(guān)聯(lián)名了,那么在關(guān)聯(lián)名后加一個(gè)數(shù)字。
· 總
6、是加上AS關(guān)鍵字,因?yàn)檫@樣的顯示聲明易于閱讀。
· 為計(jì)算出的數(shù)據(jù)命名時(shí),用一個(gè)將這條數(shù)據(jù)存在表里時(shí)會(huì)使用的列名。
Stored procedures 過(guò)程名
· 名字一定要包含動(dòng)詞。
· 不要附加sp_或任何其他這樣的敘述性前綴或使用匈牙利表示法。
Uniform suffix 統(tǒng)一的后綴
下列后綴有統(tǒng)一的意義,能保證SQL代碼更容易被理解。在合適的時(shí)候使用正確的后綴。
· _id?獨(dú)一無(wú)二的標(biāo)識(shí)符,如主鍵。
· _status?標(biāo)識(shí)值或任何表示狀態(tài)的值,比如publication_status。
· _total?總和或某些值的和。
· _num?表示該
7、域包含數(shù)值。
· _name?表示名字。
· _seq?包含一系列數(shù)值。
· _date?表示該列包含日期。
· _tally?計(jì)數(shù)值。
· _size?大小,如文件大小或服裝大小。
· _addr?地址,有形的或無(wú)形的,如ip_addr
Query syntax 查詢語(yǔ)句
Reserved words 保留字
保留字總是大寫,如SELECT和WHERE。
最好使用保留字的全稱而不是簡(jiǎn)寫,用ABSOLUTE而不用ABS。
當(dāng)標(biāo)準(zhǔn)ANSI SQL關(guān)鍵字能完成相同的事情時(shí),不要使用數(shù)據(jù)庫(kù)服務(wù)器相關(guān)的關(guān)鍵字,這樣能增強(qiáng)可移植性。
White s
8、pace 空白字符
正確地使用空白字符對(duì)清晰的代碼十分重要。不要把代碼堆再一起或移除自然語(yǔ)言中的空格。
Spaces 空格
用空格使根關(guān)鍵字都結(jié)束在同一列上。在代碼中形成一個(gè)從上到下的“川流”,這樣幫助讀者快速掃描代碼并將關(guān)鍵字和實(shí)現(xiàn)細(xì)節(jié)分開。川流在排版時(shí)應(yīng)該避免,但是對(duì)書寫SQL語(yǔ)句是有幫助的。
注意WHERE和FROM等關(guān)鍵字,都右對(duì)齊,而真實(shí)的列名都左對(duì)齊。
注意下列情況總是加入空格:
· 在等號(hào)前后(=)
· 在逗號(hào)后(,)
· 單引號(hào)前后('),除非單引號(hào)后面是括號(hào)、逗號(hào)或分號(hào)
Line spacing 換行
總是換行的情況:
9、
· 在AND或OR前。
· 在分號(hào)后(分隔語(yǔ)句以提高可讀性)。
· 在每個(gè)關(guān)鍵詞定以后。
· 將多個(gè)列組成一個(gè)邏輯組時(shí)的逗號(hào)后。
· 將代碼分隔成相關(guān)聯(lián)的多個(gè)部分,幫助提高大段代碼的可讀性。
讓所有的關(guān)鍵字右對(duì)齊,讓所有的值左對(duì)齊,在查詢語(yǔ)句中間留出一個(gè)空隙。這樣能提高速讀代碼的速讀。
Identation 縮進(jìn)
為確保SQL的可讀性,一定要遵守下列規(guī)則。
Joins Join語(yǔ)句
Join語(yǔ)句應(yīng)該縮進(jìn)到川流的另一側(cè)并在必要的時(shí)候添加一個(gè)換行。
Subqueries 子查詢
子查詢應(yīng)該在川流的右側(cè)對(duì)齊并使用其他查詢相同的樣式。有時(shí)
10、候?qū)⒂依ㄌ?hào)單獨(dú)置于一行并同與它配對(duì)的左括號(hào)對(duì)齊是有意義的——尤其是當(dāng)存在嵌套子查詢的時(shí)候。
Preferred formalisms 推薦的形式
· 盡量使用BETWEEN而不是多個(gè)AND語(yǔ)句。
· 同樣地,使用IN()而不是多個(gè)OR語(yǔ)句。
· 當(dāng)數(shù)據(jù)輸出數(shù)據(jù)庫(kù)時(shí)需要處理時(shí),使用CASE表達(dá)式。CASE語(yǔ)句能嵌套形成更復(fù)雜的邏輯結(jié)構(gòu)。
· 盡量避免UNION語(yǔ)句和臨時(shí)表。如果數(shù)據(jù)庫(kù)架構(gòu)能夠不靠這些語(yǔ)句運(yùn)行,那么多數(shù)情況下它就不應(yīng)該依靠這些語(yǔ)句。
Create syntax 創(chuàng)建語(yǔ)句
聲明模式信息時(shí)維護(hù)可讀代碼也很重要。所以列定義的順序和分組一定要有意義。
11、
在CREATE定義中,每列要縮進(jìn)4個(gè)空格。
Choosing data types 選擇數(shù)據(jù)類型
· 盡量不使用供應(yīng)商相關(guān)的數(shù)據(jù)類型——這些類型可不能能在老系統(tǒng)上使用。
· 只在真的需要浮點(diǎn)數(shù)運(yùn)算的時(shí)候才使用REAL和FLOAT類型,否則使用NUMERIC和DECIMAL類型。浮點(diǎn)數(shù)舍入誤差是個(gè)麻煩。
Specifying default values 指定默認(rèn)類型
· 默認(rèn)值一定與列的類型相同——如果一個(gè)列的類型是DECIMAL那么就不要使用INTEGER類型作為默認(rèn)值。
· 默認(rèn)值要緊跟類型聲明并在NOT NULL聲明前。
約束和鍵
約束和鍵是
12、構(gòu)成數(shù)據(jù)庫(kù)系統(tǒng)的重要組成部分。它們能很快地變得難以閱讀和理解,所以遵從指導(dǎo)方針是很重要的。
Choosing keys 選擇鍵
設(shè)計(jì)時(shí)應(yīng)該謹(jǐn)慎選擇構(gòu)成鍵的列,因?yàn)殒I既明顯影響著性能和數(shù)據(jù)完整性。
1. 鍵在某種程度上應(yīng)該是獨(dú)一無(wú)二的。
2. 該值在不同表中的類型應(yīng)該相同并且盡量不會(huì)更改。
3. 該值是否會(huì)無(wú)法通過(guò)某種標(biāo)準(zhǔn)格式(如ISO發(fā)布的標(biāo)準(zhǔn))?如
4. 盡量讓鍵保持簡(jiǎn)單,但在適當(dāng)情況下不要害怕使用復(fù)合鍵。
以上是定義數(shù)據(jù)庫(kù)時(shí)合乎邏輯的平衡做法。當(dāng)需求變更時(shí),鍵也應(yīng)該根據(jù)情況更新。
Defining constraints 定義約束
確定鍵后,就可以用約
13、束和字值段驗(yàn)證來(lái)定義它們。
General 概述
· 表至少需要一個(gè)鍵來(lái)保證其完整性和可用性。
· 約束應(yīng)該有名字,除了UNIQUE、PRIMARY KEY和FOREIGN KEY之外。
Layout and order 布局和順序
· 在CREATE TABLE語(yǔ)句后先定義主鍵。
· 約束的定義應(yīng)該緊跟它相應(yīng)的列的定義后。
· 如果該約束與多個(gè)列相關(guān),那么讓它盡量離與其相關(guān)的列距離越近越好。實(shí)在不行就講它放在表定義的最后。
· 如果是與整個(gè)表相關(guān)聯(lián)表級(jí)別的約束,那么就將放在表的定義的最后。
· 按照字母順序安排定義,ON DELETE排在ON UPDATE前。
·
14、 有道理的話,把所有相關(guān)的語(yǔ)句對(duì)齊。比如,把所有NOT NULL定義對(duì)齊到同一列。雖然這樣的做法有些慢,但是能提高可讀性。
Validation 校驗(yàn)
· 用LIKE和SIMILAR TO約束來(lái)保證格式已知字符串的數(shù)據(jù)完整性。
· 當(dāng)數(shù)字的值的范圍可以確定時(shí),用CHECK()來(lái)防止錯(cuò)誤的值進(jìn)入數(shù)據(jù)庫(kù)或被錯(cuò)誤地轉(zhuǎn)換。大部分情況下至少要確認(rèn)值要大于零。
· CHECK()約束應(yīng)該在單獨(dú)的語(yǔ)句中以便debug。
Example:
Design to avoid
· 面向?qū)ο笤O(shè)計(jì)思想并不適用于關(guān)系型數(shù)據(jù)庫(kù)——避免這個(gè)陷阱。
· 將值存入一列并將單位存在另一列。列的定義應(yīng)該讓自己的單位不言自明以避免在應(yīng)用內(nèi)進(jìn)行合并。使用CHECK()來(lái)保證數(shù)據(jù)庫(kù)中的數(shù)據(jù)是合法的。
· EAV (Entity Attribute Value)表——用特殊的產(chǎn)品來(lái)處理無(wú)模式數(shù)據(jù)。
· 因?yàn)槟承┰颍ㄈ鐬榱藲w檔、為了劃分跨國(guó)公司的區(qū)域)將能合并在一起的表分開。這樣的設(shè)計(jì)導(dǎo)致以后必須使用UNION操作而不能直接查詢一個(gè)表。