歡迎來到裝配圖網(wǎng)! | 幫助中心 裝配圖網(wǎng)zhuangpeitu.com!
裝配圖網(wǎng)
ImageVerifierCode 換一換
首頁 裝配圖網(wǎng) > 資源分類 > DOCX文檔下載  

超實(shí)用的sql書寫規(guī)范大全sql標(biāo)準(zhǔn)格式

  • 資源ID:210921445       資源大小:253.88KB        全文頁數(shù):11頁
  • 資源格式: DOCX        下載積分:9.98積分
快捷下載 游客一鍵下載
會(huì)員登錄下載
微信登錄下載
三方登錄下載: 微信開放平臺登錄 支付寶登錄   QQ登錄   微博登錄  
二維碼
微信掃一掃登錄
下載資源需要9.98積分
郵箱/手機(jī):
溫馨提示:
用戶名和密碼都是您填寫的郵箱或者手機(jī)號,方便查詢和重復(fù)下載(系統(tǒng)自動(dòng)生成)
支付方式: 支付寶    微信支付   
驗(yàn)證碼:   換一換

 
賬號:
密碼:
驗(yàn)證碼:   換一換
  忘記密碼?
    
友情提示
2、PDF文件下載后,可能會(huì)被瀏覽器默認(rèn)打開,此種情況可以點(diǎn)擊瀏覽器菜單,保存網(wǎng)頁到桌面,就可以正常下載了。
3、本站不支持迅雷下載,請使用電腦自帶的IE瀏覽器,或者360瀏覽器、谷歌瀏覽器下載即可。
4、本站資源下載后的文檔和圖紙-無水印,預(yù)覽文檔經(jīng)過壓縮,下載后原文更清晰。
5、試題試卷類文檔,如果標(biāo)題沒有明確說明有答案則都視為沒有答案,請知曉。

超實(shí)用的sql書寫規(guī)范大全sql標(biāo)準(zhǔn)格式

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)名§ 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 Constraints 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·TreffynnonTranslated by: wontoncoder·penghou6201. Overview 綜述你可以直接使用這些指導(dǎo)方針,或者 fork 后創(chuàng)建自己的版本 最重要的是選擇一套方針并嚴(yán)格遵守它。歡迎通過在 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 的書更簡潔一些 因?yàn)?Celko 的書包含了一些趣聞和每一條原則后的理由。將該文檔的 Markdown 格式 添加到項(xiàng)目代碼庫中或?qū)⒃擁撁娴逆溄影l(fā)送給項(xiàng)目的所有參與者要比傳閱實(shí)體書容易得多。Simon Holywell 所著的SQL 樣式指南以署名-相同方式共享 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ù)。· 保證代碼簡潔明了、沒有多余的 SQL 比如非必要的引號或括號,或者可以推導(dǎo)出的 WHERE 子句。· 必要時(shí)在 SQL 代碼中加入注釋。優(yōu)先使用 C 語言式的以 /* 開始以 */ 結(jié)束的塊注釋,或使用以 - 開始的行注釋,并在末尾換行。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 = '.vimrc'2.2 Avoid 應(yīng)避免的事情· 駝峰命名法,它不適合快速掃讀。· 描述性的前綴或匈牙利命名法比如 sp_ 或 tbl。· 復(fù)數(shù)形式,盡量使用更自然的集合術(shù)語。比如,用“staff”替代“employees”,或用“people”替代“individuals”。· 被引號包裹的標(biāo)識符(quoted identifier),如果你必須使用這樣的標(biāo)識符,最好堅(jiān)持用 SQL92 的雙引號來提高可移植性(你可能需要配置你的 SQL 服務(wù)器以支持此特性,具體取決于供應(yīng)商)。· 面向?qū)ο缶幊痰脑瓌t不該應(yīng)用到 SQL 或數(shù)據(jù)庫結(jié)構(gòu)上。3. Naming conventions 命名慣例3.1 General 一般原則· 保證名字獨(dú)一無二且不是保留字。· 保證名字長度不超過 30 個(gè)字節(jié),實(shí)際上,如果你不使用多字節(jié)字符集,就是 30 個(gè)字符。· 名字要以字母開頭,不能以下劃線結(jié)尾。· 只在名字中使用字母、數(shù)字和下劃線。· 不要在名字中出現(xiàn)連續(xù)下劃線,這樣很難辨認(rèn)。· 在名字中需要空格的地方用下劃線代替(first name 變?yōu)?first_name)。· 盡量避免使用縮寫詞。使用時(shí)一定確定這個(gè)縮寫簡明易懂。SELECT first_name  FROM staff;3.2 Tables 表名· 使用集合名稱,或在不那么理想的情況下使用復(fù)數(shù)形式。如 staff(建議使用)和 employees。· 不要使用類似 tbl 或其他的描述性的前綴或匈牙利命名法。· 表不應(yīng)該同它的列同名,反之亦然。· 盡量避免連接兩個(gè)表的名字作為關(guān)系表(relationship table)的名字。與其使用 cars_mechanics 做表名不如使用 services。3.3 Columns 列名· 總是使用單數(shù)形式。· 避免直接使用 id 做表的主標(biāo)識符。· 避免列名和表名同名,反之亦然。· 總是使用小寫字母,除非是特殊情況,如專有名詞。3.4 Aliasing or correlations 別名與關(guān)聯(lián)名· 別名應(yīng)該與它們所指的對象或表達(dá)式相關(guān)聯(lián)。· 一般來說,關(guān)聯(lián)名應(yīng)該由對象名中每一個(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.monitor_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)識符,如主鍵。· _status 標(biāo)志值或任何表示狀態(tài)的值,比如 publication_status。· _total 總和或某些值的和。· _num 表示該字段包含數(shù)值。· _name 表示名字,例如 first_name。· _seq 包含一系列值。· _date 表示該列包含日期。· _tally 計(jì)數(shù)值。· _size 大小,如文件大小或服裝大小。· _addr 地址,有形的或無形的,如 ip_addr4. Query syntax 查詢語句4.1 Reserved words 保留字關(guān)鍵字總是大寫,如 SELECT 和 WHERE。最好使用關(guān)鍵字的全稱而不是簡寫,用 ABSOLUTE 而不用 ABS。當(dāng)標(biāo)準(zhǔn) ANSI SQL 關(guān)鍵字能完成相同的事情時(shí),不要使用數(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 空白字符正確地使用空白字符對清晰的代碼十分重要。不要把代碼堆在一起或移除自然語言中的空格。4.2.1 Spaces 空格用空格使根關(guān)鍵字都結(jié)束在同一列上。在代碼中間形成一個(gè)從上到下的“川流”,這樣幫助讀者快速掃視代碼并將關(guān)鍵字和實(shí)現(xiàn)細(xì)節(jié)分開。川流在排版時(shí)應(yīng)該避免,但是對閱讀 SQL 語句是有幫助的。(SELECT f.species_name,        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,        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)鍵字,都右對齊,而實(shí)際的列名和實(shí)現(xiàn)細(xì)節(jié)都左對齊。注意下列情況總是加入空格:· 在等號(=)前后· 在逗號(,)后· 成對的單引號(')前后,除非在括號中或后面是逗號 / 分號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 前· 在分號后(分隔語句以提高可讀性)· 在每個(gè)關(guān)鍵字定義之后· 將多個(gè)列組成一個(gè)邏輯組時(shí)的逗號后· 將代碼分隔成相關(guān)聯(lián)的多個(gè)部分,幫助提高大段代碼的可讀性· 讓所有的關(guān)鍵字右對齊、所有的值左對齊,這樣就能在查詢語句中間留出一個(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.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 = '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       ON r.crew_chief_last_name = c.last_name          AND c.chief = 'Y'4.3.2 Subqueries 子查詢子查詢應(yīng)該在川流的右側(cè)對齊并使用其他查詢相同的樣式。有時(shí)候?qū)⒂依ㄌ枂为?dú)置于一行并同與它配對的左括號對齊是有意義的 尤其是當(dāng)存在嵌套子查詢的時(shí)候。SELECT r.last_name,       (SELECT MAX(YEAR(championship_date)          FROM champions AS c         WHERE c.last_name = r.last_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 推薦的形式· 盡量使用 BETWEEN 而不是多個(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 WHERE 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)上使用。· 只在真的需要浮點(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 Choosing 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)一致。· 盡量讓鍵保持簡單,但在適當(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è)鍵來保證其完整性和可用性。· 除了 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è)表的表級別的約束,那么就將它放在表定義的最后。· 按照字母順序安排定義,ON DELETE 排在 ON UPDATE 前。· 有道理的話,把所有相關(guān)的語句對齊。比如,把所有 NOT NULL 定義對齊到同一列。這樣做并不難,但是能提高可讀性。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 NULL,    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è)陷阱。· 將值存入一列并將其單位存在另一列 列的定義應(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ù)類型。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 日期時(shí)間類型· DATE· TIME· TIMESTAMP6.1.4 Binary types 二進(jìn)制類型· BINARY· BLOB· VARBINARY6.1.5 Additional types 其他類型· Boolean· INTERVAL· XML原文鏈接:sqlstyle.guide/zh/

注意事項(xiàng)

本文(超實(shí)用的sql書寫規(guī)范大全sql標(biāo)準(zhǔn)格式)為本站會(huì)員(ta****fu)主動(dòng)上傳,裝配圖網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對上載內(nèi)容本身不做任何修改或編輯。 若此文所含內(nèi)容侵犯了您的版權(quán)或隱私,請立即通知裝配圖網(wǎng)(點(diǎn)擊聯(lián)系客服),我們立即給予刪除!

溫馨提示:如果因?yàn)榫W(wǎng)速或其他原因下載失敗請重新下載,重復(fù)下載不扣分。




關(guān)于我們 - 網(wǎng)站聲明 - 網(wǎng)站地圖 - 資源地圖 - 友情鏈接 - 網(wǎng)站客服 - 聯(lián)系我們

copyright@ 2023-2025  zhuangpeitu.com 裝配圖網(wǎng)版權(quán)所有   聯(lián)系電話:18123376007

備案號:ICP2024067431-1 川公網(wǎng)安備51140202000466號


本站為文檔C2C交易模式,即用戶上傳的文檔直接被用戶下載,本站只是中間服務(wù)平臺,本站所有文檔下載所得的收益歸上傳人(含作者)所有。裝配圖網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對上載內(nèi)容本身不做任何修改或編輯。若文檔所含內(nèi)容侵犯了您的版權(quán)或隱私,請立即通知裝配圖網(wǎng),我們立即給予刪除!