《SQL開發(fā)樣式指南》，讓你的SQL代碼更加規(guī)范
點(diǎn)擊關(guān)注上方“SQL數(shù)據(jù)庫開發(fā)”，
設(shè)為“置頂或星標(biāo)”，第一時間送達(dá)干貨
General Theory?一般原則
Do 應(yīng)該做的事情
使用一致的、敘述性的名稱。 靈活使用空格和縮進(jìn)來增強(qiáng)可讀性。 存儲符合ISO-8601標(biāo)準(zhǔn)的日期格式( YYYY-MM-DD HH:MM:SS.SSSSS)。最好使用標(biāo)準(zhǔn)SQL函數(shù)而不是特定供應(yīng)商的函數(shù)以提高可移植性。 保證代碼簡潔明了并消除多余的SQL——比如非必要的引號或括號，或者可以推導(dǎo)出的多余 WHERE語句。必要時在SQL代碼中加入注釋。優(yōu)先使用C語言式的以 /*開始以*/結(jié)束的塊注釋，或使用以--開始的行注釋。
Avoid 應(yīng)避免的事情
駝峰命名法——它不適合快速掃描。 描述性的前綴或匈牙利命名法比如 sp_或tbl。復(fù)數(shù)形式——盡量使用更自然的集合術(shù)語。比如，用“staff”替代“employees”，或用“people”替代“individuals”。 需要引用號的標(biāo)識符——如果你必須使用這樣的標(biāo)識符，最好堅(jiān)持用SQL92的雙引號來提高可移植性。 面向?qū)ο缶幊痰脑瓌t不該應(yīng)用到結(jié)構(gòu)化查詢語言或數(shù)據(jù)庫結(jié)構(gòu)上。
Naming conventions 命名慣例
General 一般原則
保證名字獨(dú)一無二且不是保留字。 保證名字長度不超過30個字節(jié)。 名字要以字母開頭，不能以下劃線結(jié)尾。 只在名字中使用字母、數(shù)字和下劃線。 不要在名字中出現(xiàn)連續(xù)下劃線——這樣很難辨認(rèn)。 在名字中需要空格的地方用下劃線代替。 盡量避免使用縮寫詞。使用時一定確定這個縮寫簡明易懂。
Tables 表名
用集群名稱，或在不那么理想的情況下，復(fù)數(shù)形式。如 staff和employees。不要使用類似 tbl或其他的描述性的前綴或匈牙利命名法。表不應(yīng)該同它的列同名，反之亦然。 盡量避免連接兩個表的名字作為關(guān)系表（relationship table）的名字。與其使用 cars_mechanics做表名不如使用services。
Columns 列名
總是使用單數(shù)形式。 避免直接使用 id做表的主標(biāo)識符。避免列名同表名同名，反之亦然。 總是使用小寫字母，除非是特殊情況，如專有名詞。
Aliasing or correlations 別名與關(guān)聯(lián)名
應(yīng)該與它們別名的對象或與它們代表的表達(dá)式相關(guān)聯(lián)。 一般來說，關(guān)聯(lián)名應(yīng)該是對象名的第一個字母。 如果已經(jīng)有相同的關(guān)聯(lián)名了，那么在關(guān)聯(lián)名后加一個數(shù)字。 總是加上 AS關(guān)鍵字，因?yàn)檫@樣的顯示聲明易于閱讀。為計(jì)算出的數(shù)據(jù)命名時，用一個將這條數(shù)據(jù)存在表里時會使用的列名。
Stored procedures 過程名
名字一定要包含動詞。 不要附加 sp_或任何其他這樣的敘述性前綴或使用匈牙利表示法。
Uniform suffix 統(tǒng)一的后綴
_id獨(dú)一無二的標(biāo)識符，如主鍵。_status標(biāo)識值或任何表示狀態(tài)的值，比如publication_status。_total總和或某些值的和。_num表示該域包含數(shù)值。_name表示名字。_seq包含一系列數(shù)值。_date表示該列包含日期。_tally計(jì)數(shù)值。_size大小，如文件大小或服裝大小。_addr地址，有形的或無形的，如ip_addr
Query syntax 查詢語句
Reserved words 保留字
SELECT和WHERE。ABSOLUTE而不用ABS。
White space 空白字符
Spaces 空格
WHERE和FROM等關(guān)鍵字，都右對齊，而真實(shí)的列名都左對齊。在等號前后（ =）在逗號后（ ,）單引號前后（ '），除非單引號后面是括號、逗號或分號
Line spacing 換行
在 AND或OR前。在分號后（分隔語句以提高可讀性）。 在每個關(guān)鍵詞定以后。 將多個列組成一個邏輯組時的逗號后。 將代碼分隔成相關(guān)聯(lián)的多個部分，幫助提高大段代碼的可讀性。
Identation 縮進(jìn)
Joins Join語句
Subqueries 子查詢
Preferred formalisms 推薦的形式
盡量使用 BETWEEN而不是多個AND語句。同樣地，使用 IN()而不是多個OR語句。當(dāng)數(shù)據(jù)輸出數(shù)據(jù)庫時需要處理時，使用 CASE表達(dá)式。CASE語句能嵌套形成更復(fù)雜的邏輯結(jié)構(gòu)。盡量避免 UNION語句和臨時表。如果數(shù)據(jù)庫架構(gòu)能夠不靠這些語句運(yùn)行，那么多數(shù)情況下它就不應(yīng)該依靠這些語句。
Create syntax 創(chuàng)建語句
CREATE定義中，每列要縮進(jìn)4個空格。Choosing data types 選擇數(shù)據(jù)類型
盡量不使用供應(yīng)商相關(guān)的數(shù)據(jù)類型——這些類型可不能能在老系統(tǒng)上使用。 只在真的需要浮點(diǎn)數(shù)運(yùn)算的時候才使用 REAL和FLOAT類型，否則使用NUMERIC和DECIMAL類型。浮點(diǎn)數(shù)舍入誤差是個麻煩。
Specifying default values 指定默認(rèn)類型
默認(rèn)值一定與列的類型相同——如果一個列的類型是 DECIMAL那么就不要使用INTEGER類型作為默認(rèn)值。默認(rèn)值要緊跟類型聲明并在 NOT NULL聲明前。
Choosing keys 選擇鍵
鍵在某種程度上應(yīng)該是獨(dú)一無二的。 該值在不同表中的類型應(yīng)該相同并且盡量不會更改。 該值是否會無法通過某種標(biāo)準(zhǔn)格式（如ISO發(fā)布的標(biāo)準(zhǔn)）？如 盡量讓鍵保持簡單，但在適當(dāng)情況下不要害怕使用復(fù)合鍵。
Defining constraints 定義約束
General 概述
表至少需要一個鍵來保證其完整性和可用性。 約束應(yīng)該有名字，除了 UNIQUE、PRIMARY KEY和FOREIGN KEY之外。
Layout and order 布局和順序
在 CREATE TABLE語句后先定義主鍵。約束的定義應(yīng)該緊跟它相應(yīng)的列的定義后。 如果該約束與多個列相關(guān)，那么讓它盡量離與其相關(guān)的列距離越近越好。實(shí)在不行就講它放在表定義的最后。 如果是與整個表相關(guān)聯(lián)表級別的約束，那么就將放在表的定義的最后。 按照字母順序安排定義， ON DELETE排在ON UPDATE前。有道理的話，把所有相關(guān)的語句對齊。比如，把所有 NOT NULL定義對齊到同一列。雖然這樣的做法有些慢，但是能提高可讀性。
Validation 校驗(yàn)
用 LIKE和SIMILAR TO約束來保證格式已知字符串的數(shù)據(jù)完整性。當(dāng)數(shù)字的值的范圍可以確定時，用 CHECK()來防止錯誤的值進(jìn)入數(shù)據(jù)庫或被錯誤地轉(zhuǎn)換。大部分情況下至少要確認(rèn)值要大于零。CHECK()約束應(yīng)該在單獨(dú)的語句中以便debug。
Example：
Design to avoid
面向?qū)ο笤O(shè)計(jì)思想并不適用于關(guān)系型數(shù)據(jù)庫——避免這個陷阱。 將值存入一列并將單位存在另一列。列的定義應(yīng)該讓自己的單位不言自明以避免在應(yīng)用內(nèi)進(jìn)行合并。使用 CHECK()來保證數(shù)據(jù)庫中的數(shù)據(jù)是合法的。EAV (Entity Attribute Value)表——用特殊的產(chǎn)品來處理無模式數(shù)據(jù)。 因?yàn)槟承┰颍ㄈ鐬榱藲w檔、為了劃分跨國公司的區(qū)域）將能合并在一起的表分開。這樣的設(shè)計(jì)導(dǎo)致以后必須使用 UNION操作而不能直接查詢一個表。
——End——
后臺回復(fù)關(guān)鍵字：1024，獲取一份精心整理的技術(shù)干貨 后臺回復(fù)關(guān)鍵字：進(jìn)群，帶你進(jìn)入高手如云的交流群。 推薦閱讀 這是一個能學(xué)到技術(shù)的公眾號，歡迎關(guān)注
點(diǎn)擊「閱讀原文」了解SQL訓(xùn)練營
評論
圖片
表情