《超實用的sql書寫規(guī)范大全sql標準格式》由會員分享，可在線閱讀，更多相關《超實用的sql書寫規(guī)范大全sql標準格式（11頁珍藏版）》請在裝配圖網上搜索。
1、SQL編碼樣式書寫規(guī)范指南（全）SQL是數(shù)據(jù)庫查詢語言，MIMIC、eICU數(shù)據(jù)庫等數(shù)據(jù)提取可以使用SQL語言來提取，今天分享一篇文檔，主要介紹SQL編程需要注意的事項。以下是正文。目 錄 1. Overview 綜述 2. General 一般原則 2.1 Do 應該做的事情 2.2 Avoid 應避免的事情 3. Naming conventions 命名慣例 3.1 General 一般原則 3.2 Tables 表名 3.3 Columns 列名 3.4 Aliasing or correlations 別名與關聯(lián)名 3.5 Stored procedures 存儲過程名 3.6 Un
2、iform suffix 統(tǒng)一的后綴 4. Query syntax 查詢語句 4.1 Reserved words 保留字 4.2 White space 空白字符 4.3 Indentation 縮進 4.4 Preferred formalisms 推薦的形式 5. Create syntax 創(chuàng)建語句 5.1 Choosing data types 選擇數(shù)據(jù)類型 5.2 Specifying default values 指定默認類型 5.3 Constraints and keys 約束和鍵 5.4 Design to avoid 應該避免的設計 6. 附錄 6.1 Column d
3、ata types 列的數(shù)據(jù)類型這篇文檔翻譯自以署名-相同方式共享 4.0 國際協(xié)議發(fā)布的sqlstyle.guide，譯文以與原文同樣的協(xié)議發(fā)布。by Simon HolywellTreffynnonTranslated by: wontoncoderpenghou6201. Overview 綜述你可以直接使用這些指導方針，或者 fork 后創(chuàng)建自己的版本 最重要的是選擇一套方針并嚴格遵守它。歡迎通過在 GitHub 上提交 issue 或 pull request 來提交建議或修復 bug。為了讓閱讀了 Joe Celko 的SQL ProgrammingStyle的團隊能更容易采用這套
4、規(guī)則，這套原則被設計成與該書兼容的形式。本指南在某些領域嚴一些，在另一些領域松一些。當然本指南比 Celko 的書更簡潔一些 因為 Celko 的書包含了一些趣聞和每一條原則后的理由。將該文檔的 Markdown 格式 添加到項目代碼庫中或將該頁面的鏈接發(fā)送給項目的所有參與者要比傳閱實體書容易得多。Simon Holywell 所著的SQL 樣式指南以署名-相同方式共享 4.0 國際協(xié)議發(fā)布，改編自sqlstyle.guide。2. General 一般原則2.1 Do 應該做的事情 使用一致的、描述性的名稱。 合理地使用空格和縮進來增強可讀性。 存儲符合 ISO-8601 標準的日期格式（Y
5、YYY-MM-DD HH:MM:SS.SSSSS）。 為了提高可移植性，最好僅使用標準 SQL 函數(shù)而不是特定供應商的函數(shù)。 保證代碼簡潔明了、沒有多余的 SQL 比如非必要的引號或括號，或者可以推導出的 WHERE 子句。 必要時在 SQL 代碼中加入注釋。優(yōu)先使用 C 語言式的以 /* 開始以 */ 結束的塊注釋，或使用以 - 開始的行注釋，并在末尾換行。SELECTfile_hash-storedssdeephashFROMfile_systemWHEREfile_name=.vimrc;/*Updatingthefilerecordafterwritingtothefile*/UPDA
6、TEfile_systemSETfile_modified_date=1980-02-2213:19:01.00000,file_size=209732WHEREfile_name=.vimrc;2.2 Avoid 應避免的事情 駝峰命名法，它不適合快速掃讀。 描述性的前綴或匈牙利命名法比如 sp_ 或 tbl。 復數(shù)形式，盡量使用更自然的集合術語。比如，用“staff”替代“employees”，或用“people”替代“individuals”。 被引號包裹的標識符（quoted identifier），如果你必須使用這樣的標識符，最好堅持用 SQL92 的雙引號來提高可移植性（你可能需要
7、配置你的 SQL 服務器以支持此特性，具體取決于供應商）。 面向對象編程的原則不該應用到 SQL 或數(shù)據(jù)庫結構上。3. Naming conventions 命名慣例3.1 General 一般原則 保證名字獨一無二且不是保留字。 保證名字長度不超過 30 個字節(jié)，實際上，如果你不使用多字節(jié)字符集，就是 30 個字符。 名字要以字母開頭，不能以下劃線結尾。 只在名字中使用字母、數(shù)字和下劃線。 不要在名字中出現(xiàn)連續(xù)下劃線，這樣很難辨認。 在名字中需要空格的地方用下劃線代替（first name 變?yōu)?first_name）。 盡量避免使用縮寫詞。使用時一定確定這個縮寫簡明易懂。SELECTfir
8、st_nameFROMstaff;3.2 Tables 表名 使用集合名稱，或在不那么理想的情況下使用復數(shù)形式。如 staff（建議使用）和 employees。 不要使用類似 tbl 或其他的描述性的前綴或匈牙利命名法。 表不應該同它的列同名，反之亦然。 盡量避免連接兩個表的名字作為關系表（relationship table）的名字。與其使用 cars_mechanics 做表名不如使用 services。3.3 Columns 列名 總是使用單數(shù)形式。 避免直接使用 id 做表的主標識符。 避免列名和表名同名，反之亦然。 總是使用小寫字母，除非是特殊情況，如專有名詞。3.4 Aliasi
9、ng or correlations 別名與關聯(lián)名 別名應該與它們所指的對象或表達式相關聯(lián)。 一般來說，關聯(lián)名應該由對象名中每一個單詞的首字母組成。 如果已經有相同的關聯(lián)名了，那么在關聯(lián)名后加一個數(shù)字。 總是加上 AS 關鍵字，因為這樣的明確聲明易于閱讀。 為計算出的數(shù)據(jù)（SUM() 或 AVG()）命名時，用一個將這條數(shù)據(jù)存在表中時會使用的列名。SELECTfirst_nameASfnFROMstaffASs1JOINstudentsASs2ONs2.mentor_id=s1.staff_num;SELECTSUM(s.monitor_tally)ASmonitor_totalFROMsta
10、ffASs;3.5 Stored procedures 存儲過程名名字一定要包含動詞。不要附加 sp_ 或任何其他這樣的描述性的前綴或使用匈牙利表示法。3.6 Uniform suffix 統(tǒng)一的后綴下列后綴有統(tǒng)一的意義，能保證 SQL 代碼更容易理解。在合適的時候使用正確的后綴。 _id 獨一無二的標識符，如主鍵。 _status 標志值或任何表示狀態(tài)的值，比如 publication_status。 _total 總和或某些值的和。 _num 表示該字段包含數(shù)值。 _name 表示名字，例如 first_name。 _seq 包含一系列值。 _date 表示該列包含日期。 _tally 計
11、數(shù)值。 _size 大小，如文件大小或服裝大小。 _addr 地址，有形的或無形的，如 ip_addr4. Query syntax 查詢語句4.1 Reserved words 保留字關鍵字總是大寫，如 SELECT 和 WHERE。最好使用關鍵字的全稱而不是簡寫，用 ABSOLUTE 而不用 ABS。當標準 ANSI SQL 關鍵字能完成相同的事情時，不要使用數(shù)據(jù)庫服務器特定的關鍵字，這樣能增強可移植性。SELECTmodel_numFROMphonesASpWHEREp.release_date2014-09-30;4.2 White space 空白字符正確地使用空白字符對清晰的代碼十
12、分重要。不要把代碼堆在一起或移除自然語言中的空格。4.2.1 Spaces 空格用空格使根關鍵字都結束在同一列上。在代碼中間形成一個從上到下的“川流”，這樣幫助讀者快速掃視代碼并將關鍵字和實現(xiàn)細節(jié)分開。川流在排版時應該避免，但是對閱讀 SQL 語句是有幫助的。(SELECTf.species_name,AVG(f.height)ASaverage_height,AVG(f.diameter)ASaverage_diameterFROMfloraASfWHEREf.species_name=BanksiaORf.species_name=SheoakORf.species_name=Wattle
13、GROUPBYf.species_name,f.observation_date)UNIONALL(SELECTb.species_name,AVG(b.height)ASaverage_height,AVG(b.diameter)ASaverage_diameterFROMbotanic_garden_floraASbWHEREb.species_name=BanksiaORb.species_name=SheoakORb.species_name=WattleGROUPBYb.species_name,b.observation_date);注意 SELECT 和 FROM 等關鍵字，都右
14、對齊，而實際的列名和實現(xiàn)細節(jié)都左對齊。注意下列情況總是加入空格： 在等號（=）前后 在逗號（,）后 成對的單引號（）前后，除非在括號中或后面是逗號 / 分號SELECTa.title,a.release_date,a.recording_dateFROMalbumsASaWHEREa.title=CharcoalLaneORa.title=TheNewDanger;4.2.2 Line spacing 換行總是換行的情況： 在 AND 或 OR 前 在分號后（分隔語句以提高可讀性） 在每個關鍵字定義之后 將多個列組成一個邏輯組時的逗號后 將代碼分隔成相關聯(lián)的多個部分，幫助提高大段代碼的可讀性
15、讓所有的關鍵字右對齊、所有的值左對齊，這樣就能在查詢語句中間留出一個空隙，有助于快速掃讀整個查詢的定義。INSERTINTOalbums(title,release_date,recording_date)VALUES(CharcoalLane,1990-01-0101:01:01.00000,1990-01-0101:01:01.00000),(TheNewDanger,2008-01-0101:01:01.00000,1990-01-0101:01:01.00000);UPDATEalbumsSETrelease_date=1990-01-0101:01:01.00000WHEREtitl
16、e=TheNewDanger;SELECTa.title,a.release_date,a.recording_date,a.production_date-將所有的日期放在一起FROMalbumsASaWHEREa.title=CharcoalLaneORa.title=TheNewDanger;4.3 Indentation 縮進為確保 SQL 的可讀性，一定要遵守下列規(guī)則。4.3.1 Joins Join 語句Join 語句應該縮進到川流的另一側并在必要的時候添加一個換行。SELECTr.last_nameFROMridersASrINNERJOINbikesASbONr.bike_vi
17、n_num=b.vin_numANDb.engine_tally2INNERJOINcrewAScONr.crew_chief_last_name=c.last_nameANDc.chief=Y;4.3.2 Subqueries 子查詢子查詢應該在川流的右側對齊并使用其他查詢相同的樣式。有時候將右括號單獨置于一行并同與它配對的左括號對齊是有意義的 尤其是當存在嵌套子查詢的時候。SELECTr.last_name,(SELECTMAX(YEAR(championship_date)FROMchampionsAScWHEREc.last_name=r.last_nameANDc.confirmed
18、=Y)ASlast_championship_yearFROMridersASrWHEREr.last_nameIN(SELECTc.last_nameFROMchampionsAScWHEREYEAR(championship_date)2008ANDc.confirmed=Y);4.4 Preferred formalisms 推薦的形式 盡量使用 BETWEEN 而不是多個 AND 語句。 同樣地，使用 IN() 而不是多個 OR 語句。 當數(shù)據(jù)輸出數(shù)據(jù)庫時需要處理時，使用 CASE 表達式。CASE 語句能嵌套形成更復雜的邏輯結構。 盡量避免 UNION 語句和臨時表。如果數(shù)據(jù)庫架構能
19、夠不靠這些語句運行，那么多數(shù)情況下它就不應該依靠這些語句。SELECTCASEpostcodeWHENBN1THENBrightonWHENEH1THENEdinburghENDAScityFROMoffice_locationsWHEREcountry=UnitedKingdomANDopening_timeBETWEEN8AND9ANDpostcodeIN(EH1,BN1,NN1,KW1);5. Create syntax 創(chuàng)建語句聲明模式信息時維護可讀代碼也很重要。所以列定義的順序和分組一定要有意義。在 CREATE 定義中，每個列定義要縮進 4 個空格。5.1 Choosing dat
20、a types 選擇數(shù)據(jù)類型 盡量不使用供應商相關的數(shù)據(jù)類型 這些類型不可移植甚至有可能不能在相同供應商的舊版本系統(tǒng)上使用。 只在真的需要浮點數(shù)運算的時候才使用 REAL 和 FLOAT 類型，否則使用 NUMERIC 和 DECIMAL 類型。浮點數(shù)舍入誤差是個麻煩。5.2 Specifying default values 指定默認類型 默認值一定與列的類型相同 如果一個列的類型是 DECIMAL 那么就不要使用 INTEGER 類型的值作為默認值。 默認值要緊跟類型聲明并在 NOT NULL 聲明前。5.3 Constraints and keys 約束和鍵約束和鍵是構成數(shù)據(jù)庫系統(tǒng)的重要
21、組成部分。它們能很快地變得難以閱讀和理解，所以遵從指導方針是很重要的。5.3.1 Choosing keys 選擇鍵設計時應該謹慎選擇構成鍵的列，因為鍵會影響性能和數(shù)據(jù)完整性。 鍵在某種程度上應該是獨一無二的。 該值在不同表中的類型應該相同并且盡量不會更改。 該值能否通過某種標準格式（如 ISO 發(fā)布的標準）？鼓勵與前面第二點一致。 盡量讓鍵保持簡單，但在適當情況下不要害怕使用復合鍵。以上是定義數(shù)據(jù)庫時合乎邏輯的平衡做法。當需求變更時，鍵也應該根據(jù)情況更新。5.3.2 Defining constraints 定義約束確定鍵后，就可以用約束和字值段驗證來定義它們。5.3.2.1 General
22、 概述 表至少需要一個鍵來保證其完整性和可用性。 除了 UNIQUE 、PRIMARY KEY 和 FOREIGN KEY 之外（數(shù)據(jù)庫供應商會提供相應的檢查），約束應該有名字。5.3.2.2 Layout and order 布局和順序 在 CREATE TABLE 語句后先定義主鍵。 約束的定義應該緊跟它相應的列的定義后。 如果該約束與多個列相關，那么讓它離相關的列越近越好。實在不行就將它放在表定義的最后。 如果是應用于整個表的表級別的約束，那么就將它放在表定義的最后。 按照字母順序安排定義，ON DELETE 排在 ON UPDATE 前。 有道理的話，把所有相關的語句對齊。比如，把所有
23、 NOT NULL 定義對齊到同一列。這樣做并不難，但是能提高可讀性。5.3.2.3 Validation 校驗 當字符串的格式已知時，用 LIKE 和 SIMILAR TO 約束來保證它們的完整性。 當數(shù)值的范圍可以確定時，用范圍 CHECK() 來防止錯誤的值進入數(shù)據(jù)庫或在沒有提示的情況下截斷。大部分情況下至少要確認數(shù)值大于零。 CHECK() 約束應該在單獨的子句中以便 debug。CREATETABLEstaff(PRIMARYKEY(staff_num),staff_numINT(5)NOTNULL,first_nameVARCHAR(100)NOTNULL,pens_in_draw
24、erINT(2)NOTNULL,CONSTRAINTpens_in_drawer_rangeCHECK(pens_in_drawerBETWEEN1AND99);5.4 Design to avoid 應該避免的設計 在關系型數(shù)據(jù)庫的設計中應用面向對象設計思想（原則） 面向對象設計思想（原則）并不能很好地適用于關系型數(shù)據(jù)庫的設計，避免這個陷阱。 將值存入一列并將其單位存在另一列 列的定義應該讓自己的單位不言自明以避免在應用內進行合并。使用 CHECK() 來保證插入的數(shù)據(jù)是合法的。 EAV (Entity Attribute Value) 表 應該用專門的產品來處理這樣的無模式數(shù)據(jù)。 因為某些
25、原因（如為了根據(jù)時間歸檔、為了劃分跨國組織的區(qū)域）將本應該放在一個表中的數(shù)據(jù)分到多個表中 這樣的設計導致以后必須使用 UNION 操作而不能直接查詢一個表。6. 附錄6.1 Column data types 列的數(shù)據(jù)類型出于在數(shù)據(jù)庫引擎之間達到最大程度兼容的目的，下面是一些建議使用的列數(shù)據(jù)類型。6.1.1 Character types 字符型 CHAR CLOB VARCHAR6.1.2 Numeric types 數(shù)值型精確數(shù)值類型 BIGINT DECIMAL DECFLOAT INTEGER NUMERIC SMALLINT近似數(shù)值類型 DOUBLE PRECISION FLOAT REAL6.1.3 Datetime types 日期時間類型 DATE TIME TIMESTAMP6.1.4 Binary types 二進制類型 BINARY BLOB VARBINARY6.1.5 Additional types 其他類型 Boolean INTERVAL XML原文鏈接：sqlstyle.guide/zh/
超實用的sql書寫規(guī)范大全sql標準格式
