《超實(shí)用的sql書寫規(guī)范大全sql標(biāo)準(zhǔn)格式》由會(huì)員分享，可在線閱讀，更多相關(guān)《超實(shí)用的sql書寫規(guī)范大全sql標(biāo)準(zhǔn)格式（11頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、SQL編碼樣式書寫規(guī)范指南（全） SQL是數(shù)據(jù)庫查詢語言，MIMIC、eICU數(shù)據(jù)庫等數(shù)據(jù)提取可以使用SQL語言來提取，今天分享一篇文檔，主要介紹SQL編程需要注意的事項(xiàng)。 以下是正文。 目? 錄 · 1. Overview 綜述 · 2. General 一般原則 § 2.1 Do 應(yīng)該做的事情 § 2.2 Avoid 應(yīng)避免的事情 · 3. Naming conventions 命名慣例 § 3.1 General 一般原則 § 3.2 Tables 表名 § 3.3 Columns 列名 § 3.4 Aliasing or correlations 別名與關(guān)聯(lián)

2、名 § 3.5 Stored procedures 存儲(chǔ)過程名 § 3.6 Uniform suffix 統(tǒng)一的后綴 · 4. Query syntax 查詢語句 § 4.1 Reserved words 保留字 § 4.2 White space 空白字符 § 4.3 Indentation 縮進(jìn) § 4.4 Preferred formalisms 推薦的形式 · 5. Create syntax 創(chuàng)建語句 § 5.1 Choosing data types 選擇數(shù)據(jù)類型 § 5.2 Specifying default values 指定默認(rèn)類型 § 5.3 Con

3、straints and keys 約束和鍵 § 5.4 Design to avoid 應(yīng)該避免的設(shè)計(jì) · 6. 附錄 § 6.1 Column data types 列的數(shù)據(jù)類型 這篇文檔翻譯自以署名-相同方式共享 4.0 國際協(xié)議發(fā)布的 sqlstyle.guide，譯文以與原文同樣的協(xié)議發(fā)布。 by Simon Holywell·@Treffynnon Translated by: wontoncoder·penghou620 1. Overview 綜述 你可以直接使用這些指導(dǎo)方針，或者 fork 后創(chuàng)建自己的版本 —— 最重要的是選擇一套方針并嚴(yán)格遵守它。

4、歡迎通過在 GitHub 上提交 issue 或 pull request 來提交建議或修復(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)?Celko 的書包含了一些趣聞和每一條原則后的理由。 將該文檔的 Markdown 格式 添加到項(xiàng)目代碼庫中或?qū)⒃擁撁娴逆溄影l(fā)送給項(xiàng)目的所有參與者要比傳閱實(shí)體書容易得多。 Simon Holywell 所著的《SQL 樣式指南》以署名-相同方式共享

5、4.0 國際協(xié)議發(fā)布，改編自sqlstyle.guide。 2. General 一般原則 2.1 Do 應(yīng)該做的事情 · 使用一致的、描述性的名稱。 · 合理地使用空格和縮進(jìn)來增強(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)出的 WHERE 子句。 · 必要時(shí)在 SQL 代碼中加入注釋。優(yōu)先使用 C 語言式的以 /* 開始以 */ 結(jié)束的塊注釋，或使

6、用以 -- 開始的行注釋，并在末尾換行。 SELECT?file_hash??--?stored?ssdeep?hash ??FROM?file_system ?WHERE?file_name?=?'.vimrc'; /*?Updating?the?file?record?after?writing?to?the?file?*/ UPDATE?file_system ???SET?file_modified_date?=?'1980-02-22?13:19:01.00000', ???????file_size?=?209732 ?WHERE?file_name?=?'.vim

7、rc'; 2.2 Avoid 應(yīng)避免的事情 · 駝峰命名法，它不適合快速掃讀。 · 描述性的前綴或匈牙利命名法比如 sp_ 或 tbl。 · 復(fù)數(shù)形式，盡量使用更自然的集合術(shù)語。比如，用“staff”替代“employees”，或用“people”替代“individuals”。 · 被引號(hào)包裹的標(biāo)識(shí)符（quoted identifier），如果你必須使用這樣的標(biāo)識(shí)符，最好堅(jiān)持用 SQL92 的雙引號(hào)來提高可移植性（你可能需要配置你的 SQL 服務(wù)器以支持此特性，具體取決于供應(yīng)商）。 · 面向?qū)ο缶幊痰脑瓌t不該應(yīng)用到 SQL 或數(shù)據(jù)庫結(jié)構(gòu)上。 3. Naming conventi

8、ons 命名慣例 3.1 General 一般原則 · 保證名字獨(dú)一無二且不是保留字。 · 保證名字長(zhǎng)度不超過 30 個(gè)字節(jié)，實(shí)際上，如果你不使用多字節(jié)字符集，就是 30 個(gè)字符。 · 名字要以字母開頭，不能以下劃線結(jié)尾。 · 只在名字中使用字母、數(shù)字和下劃線。 · 不要在名字中出現(xiàn)連續(xù)下劃線，這樣很難辨認(rèn)。 · 在名字中需要空格的地方用下劃線代替（first name 變?yōu)?first_name）。 · 盡量避免使用縮寫詞。使用時(shí)一定確定這個(gè)縮寫簡(jiǎn)明易懂。 SELECT?first_name ??FROM?staff; 3.2 Tables 表名 · 使用集合名稱，或

9、在不那么理想的情況下使用復(fù)數(shù)形式。如 staff（建議使用）和 employees。 · 不要使用類似 tbl 或其他的描述性的前綴或匈牙利命名法。 · 表不應(yīng)該同它的列同名，反之亦然。 · 盡量避免連接兩個(gè)表的名字作為關(guān)系表（relationship table）的名字。與其使用 cars_mechanics 做表名不如使用 services。 3.3 Columns 列名 · 總是使用單數(shù)形式。 · 避免直接使用 id 做表的主標(biāo)識(shí)符。 · 避免列名和表名同名，反之亦然。 · 總是使用小寫字母，除非是特殊情況，如專有名詞。 3.4 Aliasing or correlat

10、ions 別名與關(guān)聯(lián)名 · 別名應(yīng)該與它們所指的對(duì)象或表達(dá)式相關(guān)聯(lián)。 · 一般來說，關(guān)聯(lián)名應(yīng)該由對(duì)象名中每一個(gè)單詞的首字母組成。 · 如果已經(jīng)有相同的關(guān)聯(lián)名了，那么在關(guān)聯(lián)名后加一個(gè)數(shù)字。 · 總是加上 AS 關(guān)鍵字，因?yàn)檫@樣的明確聲明易于閱讀。 · 為計(jì)算出的數(shù)據(jù)（SUM() 或 AVG()）命名時(shí)，用一個(gè)將這條數(shù)據(jù)存在表中時(shí)會(huì)使用的列名。 SELECT?first_name?AS?fn ??FROM?staff?AS?s1 ??JOIN?students?AS?s2 ????ON?s2.mentor_id?=?s1.staff_num; SELECT?SUM(s.moni

11、tor_tally)?AS?monitor_total ??FROM?staff?AS?s; 3.5 Stored procedures 存儲(chǔ)過程名 名字一定要包含動(dòng)詞。不要附加 sp_ 或任何其他這樣的描述性的前綴或使用匈牙利表示法。 3.6 Uniform suffix 統(tǒng)一的后綴 下列后綴有統(tǒng)一的意義，能保證 SQL 代碼更容易理解。在合適的時(shí)候使用正確的后綴。 · _id —— 獨(dú)一無二的標(biāo)識(shí)符，如主鍵。 · _status —— 標(biāo)志值或任何表示狀態(tài)的值，比如 publication_status。 · _total —— 總和或某些值的和。 · _num —— 表

12、示該字段包含數(shù)值。 · _name —— 表示名字，例如 first_name。 · _seq —— 包含一系列值。 · _date —— 表示該列包含日期。 · _tally —— 計(jì)數(shù)值。 · _size —— 大小，如文件大小或服裝大小。 · _addr —— 地址，有形的或無形的，如 ip_addr 4. Query syntax 查詢語句 4.1 Reserved words 保留字 關(guān)鍵字總是大寫，如 SELECT 和 WHERE。 最好使用關(guān)鍵字的全稱而不是簡(jiǎn)寫，用 ABSOLUTE 而不用 ABS。 當(dāng)標(biāo)準(zhǔn) ANSI SQL 關(guān)鍵字能完成相同的事情時(shí)，不要

13、使用數(shù)據(jù)庫服務(wù)器特定的關(guān)鍵字，這樣能增強(qiáng)可移植性。 SELECT?model_num ??FROM?phones?AS?p ?WHERE?p.release_date?>?'2014-09-30'; 4.2 White space 空白字符 正確地使用空白字符對(duì)清晰的代碼十分重要。不要把代碼堆在一起或移除自然語言中的空格。 4.2.1 Spaces 空格 用空格使根關(guān)鍵字都結(jié)束在同一列上。在代碼中間形成一個(gè)從上到下的“川流”，這樣幫助讀者快速掃視代碼并將關(guān)鍵字和實(shí)現(xiàn)細(xì)節(jié)分開。川流在排版時(shí)應(yīng)該避免，但是對(duì)閱讀 SQL 語句是有幫助的。 (SELECT?f.species_name

14、, ????????AVG(f.height)?AS?average_height,?AVG(f.diameter)?AS?average_diameter ???FROM?flora?AS?f ??WHERE?f.species_name?=?'Banksia' ?????OR?f.species_name?=?'Sheoak' ?????OR?f.species_name?=?'Wattle' ??GROUP?BY?f.species_name,?f.observation_date) ??UNION?ALL (SELECT?b.species_name, ???

15、?????AVG(b.height)?AS?average_height,?AVG(b.diameter)?AS?average_diameter ???FROM?botanic_garden_flora?AS?b ??WHERE?b.species_name?=?'Banksia' ?????OR?b.species_name?=?'Sheoak' ?????OR?b.species_name?=?'Wattle' ??GROUP?BY?b.species_name,?b.observation_date); 注意 SELECT 和 FROM 等關(guān)鍵字，都右對(duì)齊，而實(shí)際的列名和實(shí)

16、現(xiàn)細(xì)節(jié)都左對(duì)齊。 注意下列情況總是加入空格： · 在等號(hào)（=）前后 · 在逗號(hào)（,）后 · 成對(duì)的單引號(hào)（'）前后，除非在括號(hào)中或后面是逗號(hào) / 分號(hào) SELECT?a.title,?a.release_date,?a.recording_date ??FROM?albums?AS?a ?WHERE?a.title?=?'Charcoal?Lane' ????OR?a.title?=?'The?New?Danger'; 4.2.2 Line spacing 換行 總是換行的情況： · 在 AND 或 OR 前 · 在分號(hào)后（分隔語句以提高可讀性） · 在每個(gè)關(guān)鍵字定義

17、之后 · 將多個(gè)列組成一個(gè)邏輯組時(shí)的逗號(hào)后 · 將代碼分隔成相關(guān)聯(lián)的多個(gè)部分，幫助提高大段代碼的可讀性 · 讓所有的關(guān)鍵字右對(duì)齊、所有的值左對(duì)齊，這樣就能在查詢語句中間留出一個(gè)空隙，有助于快速掃讀整個(gè)查詢的定義。 INSERT?INTO?albums?(title,?release_date,?recording_date) VALUES?('Charcoal?Lane',?'1990-01-01?01:01:01.00000',?'1990-01-01?01:01:01.00000'), ???????('The?New?Danger',?'2008-01-01?01:01:01

18、.00000',?'1990-01-01?01:01:01.00000'); UPDATE?albums ???SET?release_date?=?'1990-01-01?01:01:01.00000' ?WHERE?title?=?'The?New?Danger'; SELECT?a.title, ???????a.release_date,?a.recording_date,?a.production_date?--?將所有的日期放在一起 ??FROM?albums?AS?a ?WHERE?a.title?=?'Charcoal?Lane' ????OR?a.title?

19、=?'The?New?Danger'; 4.3 Indentation 縮進(jìn) 為確保 SQL 的可讀性，一定要遵守下列規(guī)則。 4.3.1 Joins Join 語句 Join 語句應(yīng)該縮進(jìn)到川流的另一側(cè)并在必要的時(shí)候添加一個(gè)換行。 SELECT?r.last_name ??FROM?riders?AS?r ???????INNER?JOIN?bikes?AS?b ???????ON?r.bike_vin_num?=?b.vin_num ??????????AND?b.engine_tally?>?2 ???????INNER?JOIN?crew?AS?c ??????

20、?ON?r.crew_chief_last_name?=?c.last_name ??????????AND?c.chief?=?'Y'; 4.3.2 Subqueries 子查詢 子查詢應(yīng)該在川流的右側(cè)對(duì)齊并使用其他查詢相同的樣式。有時(shí)候?qū)⒂依ㄌ?hào)單獨(dú)置于一行并同與它配對(duì)的左括號(hào)對(duì)齊是有意義的 —— 尤其是當(dāng)存在嵌套子查詢的時(shí)候。 SELECT?r.last_name, ???????(SELECT?MAX(YEAR(championship_date)) ??????????FROM?champions?AS?c ?????????WHERE?c.last_name?=?r.l

21、ast_name ???????????AND?c.confirmed?=?'Y')?AS?last_championship_year ??FROM?riders?AS?r ?WHERE?r.last_name?IN ???????(SELECT?c.last_name ??????????FROM?champions?AS?c ?????????WHERE?YEAR(championship_date)?>?'2008' ???????????AND?c.confirmed?=?'Y'); 4.4 Preferred formalisms 推薦的形式 · 盡量使用 BET

22、WEEN 而不是多個(gè) AND 語句。 · 同樣地，使用 IN() 而不是多個(gè) OR 語句。 · 當(dāng)數(shù)據(jù)輸出數(shù)據(jù)庫時(shí)需要處理時(shí)，使用 CASE 表達(dá)式。CASE 語句能嵌套形成更復(fù)雜的邏輯結(jié)構(gòu)。 · 盡量避免 UNION 語句和臨時(shí)表。如果數(shù)據(jù)庫架構(gòu)能夠不靠這些語句運(yùn)行，那么多數(shù)情況下它就不應(yīng)該依靠這些語句。 SELECT?CASE?postcode ???????WHEN?'BN1'?THEN?'Brighton' ???????WHEN?'EH1'?THEN?'Edinburgh' ???????END?AS?city ??FROM?office_locations ?WH

23、ERE?country?=?'United?Kingdom' ???AND?opening_time?BETWEEN?8?AND?9 ???AND?postcode?IN?('EH1',?'BN1',?'NN1',?'KW1'); 5. Create syntax 創(chuàng)建語句 聲明模式信息時(shí)維護(hù)可讀代碼也很重要。所以列定義的順序和分組一定要有意義。 在 CREATE 定義中，每個(gè)列定義要縮進(jìn) 4 個(gè)空格。 5.1 Choosing data types 選擇數(shù)據(jù)類型 · 盡量不使用供應(yīng)商相關(guān)的數(shù)據(jù)類型 —— 這些類型不可移植甚至有可能不能在相同供應(yīng)商的舊版本系統(tǒng)上使用。 · 只在

24、真的需要浮點(diǎn)數(shù)運(yùn)算的時(shí)候才使用 REAL 和 FLOAT 類型，否則使用 NUMERIC 和 DECIMAL 類型。浮點(diǎn)數(shù)舍入誤差是個(gè)麻煩。 5.2 Specifying default values 指定默認(rèn)類型 · 默認(rèn)值一定與列的類型相同 —— 如果一個(gè)列的類型是 DECIMAL 那么就不要使用 INTEGER 類型的值作為默認(rèn)值。 · 默認(rèn)值要緊跟類型聲明并在 NOT NULL 聲明前。 5.3 Constraints and keys 約束和鍵 約束和鍵是構(gòu)成數(shù)據(jù)庫系統(tǒng)的重要組成部分。它們能很快地變得難以閱讀和理解，所以遵從指導(dǎo)方針是很重要的。 5.3.1 Choosin

25、g keys 選擇鍵 設(shè)計(jì)時(shí)應(yīng)該謹(jǐn)慎選擇構(gòu)成鍵的列，因?yàn)殒I會(huì)影響性能和數(shù)據(jù)完整性。 · 鍵在某種程度上應(yīng)該是獨(dú)一無二的。 · 該值在不同表中的類型應(yīng)該相同并且盡量不會(huì)更改。 · 該值能否通過某種標(biāo)準(zhǔn)格式（如 ISO 發(fā)布的標(biāo)準(zhǔn)）？鼓勵(lì)與前面第二點(diǎn)一致。 · 盡量讓鍵保持簡(jiǎn)單，但在適當(dāng)情況下不要害怕使用復(fù)合鍵。 以上是定義數(shù)據(jù)庫時(shí)合乎邏輯的平衡做法。當(dāng)需求變更時(shí)，鍵也應(yīng)該根據(jù)情況更新。 5.3.2 Defining constraints 定義約束 確定鍵后，就可以用約束和字值段驗(yàn)證來定義它們。 5.3.2.1 General 概述 · 表至少需要一個(gè)鍵來保證其完整性和可用性

26、。 · 除了 UNIQUE 、PRIMARY KEY 和 FOREIGN KEY 之外（數(shù)據(jù)庫供應(yīng)商會(huì)提供相應(yīng)的檢查），約束應(yīng)該有名字。 5.3.2.2 Layout and order 布局和順序 · 在 CREATE TABLE 語句后先定義主鍵。 · 約束的定義應(yīng)該緊跟它相應(yīng)的列的定義后。 · 如果該約束與多個(gè)列相關(guān)，那么讓它離相關(guān)的列越近越好。實(shí)在不行就將它放在表定義的最后。 · 如果是應(yīng)用于整個(gè)表的表級(jí)別的約束，那么就將它放在表定義的最后。 · 按照字母順序安排定義，ON DELETE 排在 ON UPDATE 前。 · 有道理的話，把所有相關(guān)的語句對(duì)齊。比如，把所有

27、 NOT NULL 定義對(duì)齊到同一列。這樣做并不難，但是能提高可讀性。 5.3.2.3 Validation 校驗(yàn) · 當(dāng)字符串的格式已知時(shí)，用 LIKE 和 SIMILAR TO 約束來保證它們的完整性。 · 當(dāng)數(shù)值的范圍可以確定時(shí)，用范圍 CHECK() 來防止錯(cuò)誤的值進(jìn)入數(shù)據(jù)庫或在沒有提示的情況下截?cái)?。大部分情況下至少要確認(rèn)數(shù)值大于零。 · CHECK() 約束應(yīng)該在單獨(dú)的子句中以便 debug。 CREATE?TABLE?staff?( ????PRIMARY?KEY?(staff_num), ????staff_num??????INT(5)???????NOT?NUL

28、L, ????first_name?????VARCHAR(100)?NOT?NULL, ????pens_in_drawer?INT(2)???????NOT?NULL, ???????????????????CONSTRAINT?pens_in_drawer_range ???????????????????CHECK(pens_in_drawer?BETWEEN?1?AND?99) ); 5.4 Design to avoid 應(yīng)該避免的設(shè)計(jì) · 在關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)中應(yīng)用面向?qū)ο笤O(shè)計(jì)思想（原則）—— 面向?qū)ο笤O(shè)計(jì)思想（原則）并不能很好地適用于關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)，避免這個(gè)陷

29、阱。 · 將值存入一列并將其單位存在另一列 —— 列的定義應(yīng)該讓自己的單位不言自明以避免在應(yīng)用內(nèi)進(jìn)行合并。使用 CHECK() 來保證插入的數(shù)據(jù)是合法的。 · EAV (Entity Attribute Value) 表 —— 應(yīng)該用專門的產(chǎn)品來處理這樣的無模式數(shù)據(jù)。 · 因?yàn)槟承┰颍ㄈ鐬榱烁鶕?jù)時(shí)間歸檔、為了劃分跨國組織的區(qū)域）將本應(yīng)該放在一個(gè)表中的數(shù)據(jù)分到多個(gè)表中 —— 這樣的設(shè)計(jì)導(dǎo)致以后必須使用 UNION 操作而不能直接查詢一個(gè)表。 6. 附錄 6.1 Column data types 列的數(shù)據(jù)類型 出于在數(shù)據(jù)庫引擎之間達(dá)到最大程度兼容的目的，下面是一些建議使用的列數(shù)據(jù)類

30、型。 6.1.1 Character types 字符型 · CHAR · CLOB · VARCHAR 6.1.2 Numeric types 數(shù)值型 精確數(shù)值類型 · BIGINT · DECIMAL · DECFLOAT · INTEGER · NUMERIC · SMALLINT 近似數(shù)值類型 · DOUBLE PRECISION · FLOAT · REAL 6.1.3 Datetime types 日期時(shí)間類型 · DATE · TIME · TIMESTAMP 6.1.4 Binary types 二進(jìn)制類型 · BINARY · BLOB · VARBINARY 6.1.5 Additional types 其他類型 · Boolean · INTERVAL · XML 原文鏈接：sqlstyle.guide/zh/