背景

已格式化的SQL并不比未格式化SQL運(yùn)行地更快。數(shù)據(jù)庫(kù)可能真的不太在意你是否把逗號(hào)放在每個(gè)字段名稱的前面或后面。為幫助你更理智和成為一名高效的SQL編寫者，我建議你遵循一些格式化的指導(dǎo)方針。在這篇文章里，我將分享如何格式化SQL語(yǔ)句來(lái)提高工作效率。我對(duì)生產(chǎn)力這樣定義，能夠從SQL得到準(zhǔn)確的結(jié)果，同時(shí)代碼容易理解，修改和調(diào)試。我只會(huì)專注于SELECT語(yǔ)句，它占到我編寫SQL的99%。格式化SQL代碼是非常個(gè)性的選擇，我很清楚，不同的人將鐘愛(ài)他們自己的格式化規(guī)則。

問(wèn)題樣例

這是一個(gè)典型的SQL使用場(chǎng)景，業(yè)務(wù)上需要這樣的報(bào)表，它的數(shù)據(jù)在三個(gè)表中，分別是customer、sales 和 location。在2015年1月，報(bào)表需要顯示位于每一個(gè)郵政編碼區(qū)域的客戶數(shù)量和總銷售額。這應(yīng)該是一個(gè)簡(jiǎn)單的SQL語(yǔ)句，它連接三個(gè)表。

數(shù)據(jù)可能有問(wèn)題

雖然SQL很容易，確保結(jié)果準(zhǔn)確才是真正的挑戰(zhàn)，以下是許多可能的原因中的一個(gè)，包括:

數(shù)據(jù)可能來(lái)自不同數(shù)據(jù)源。這意味著在不同的表中的無(wú)法保證引用完整性。簡(jiǎn)單說(shuō)，你不能假定 customer 表上的所有郵政編碼是有效的，同時(shí)在 location 表上也存在該問(wèn)題。

存取客戶數(shù)據(jù)的應(yīng)用程序，可能沒(méi)有適當(dāng)?shù)臄?shù)據(jù)驗(yàn)證。可能已經(jīng)存入不正確的郵政編碼。

postcode 表可能沒(méi)有所有郵政編碼。新的郵政編碼代碼可能被引入，但自從上次更新還沒(méi)有添加到表中。

第一原則

對(duì)我來(lái)說(shuō)，格式化SQL更多地是從SQL獲得正確的結(jié)果，因?yàn)樗忻鞔_的SQL，很容易跟蹤。我做的第一件事編寫獲取客戶總數(shù)的語(yǔ)句。這是個(gè)數(shù)字，我將在寫完整個(gè)語(yǔ)句后進(jìn)行對(duì)比。

我寫的第一條語(yǔ)句是：

SELECT

COUNT(DISTINCT cust_id) AS count_customers

FROM

customers

Result:

count_customers

“10″

這個(gè)查詢很重要，因?yàn)樗裱?第一原則(外部鏈接) 。因?yàn)闆](méi)有SQL連接，因此沒(méi)有依賴，我知道這是正確的客戶數(shù)量。我總是記下結(jié)果，因?yàn)槲铱偸切枰眠@個(gè)數(shù)字對(duì)比，在這篇文章是 10。

接下來(lái)我要做的就是添加必要的字段和表到這個(gè)查詢。我強(qiáng)調(diào)添加這個(gè)詞，因?yàn)楦鶕?jù)我遵循的格式化規(guī)則，我可以注釋掉查詢的元素來(lái)得到和我應(yīng)用第一原則時(shí)相同的結(jié)果。下面是我最終的格式化查詢，使用格式化查詢的方式。

格式化SQL

下面是我推薦的格式化的SQL，緊接后面是我進(jìn)行的格式化選擇的理由。

SELECT

0

,c.cust_post_code

,p.location

,COUNT(DISTINCT c.cust_id) number_customers

,SUM(s.total_amount) AS total_sales

FROM

customers c

JOIN post_codes p ON c.cust_post_code = p.post_code

JOIN sales s ON c.cust_id = s.cust_id

WHERE

1=1

AND s.sales_date BETWEEN '2015-01-01' AND '2015-01-31'

--AND s.order_id = 5

GROUP BY

c.cust_post_code

,p.location

總是使用表別名

這將會(huì)在你的SQL中得到證實(shí)。如果你不為參與查詢的每個(gè)字段使用 別名(外部鏈接) ，有時(shí)候在后期，具有相同名稱的字段添加到查詢中使用的某個(gè)表中。你的查詢和你的報(bào)表將出現(xiàn)一個(gè)錯(cuò)誤(發(fā)現(xiàn)重復(fù)的字段名)。

逗號(hào)在字段前

當(dāng)調(diào)試/測(cè)試我的查詢時(shí)，這讓我能輕易進(jìn)行字段注釋和取消注釋，不需要在查詢中修改任何其他行，以確保逗號(hào)在正確的地方。我看過(guò)一些文章，博主為了大事化小不得不改變另一個(gè)查詢的一部分，以確保逗號(hào)是正確的，但是你如果花大部分時(shí)間編寫和測(cè)試 SQL 語(yǔ)句，這是一個(gè)大問(wèn)題。你按這種方式將會(huì)更有效率。這個(gè)在 SELECT 和 GROUP BY 查詢部分都工作地很好。

我在開發(fā)環(huán)境使用 SELECT 0，同時(shí)傾向于進(jìn)入生產(chǎn)環(huán)境之前刪除它。它允許我把逗號(hào)放在所有字段前。如果沒(méi)有 0，我想注釋掉c.cust_post_code，它是第一個(gè)字段，我就必須注釋掉第二個(gè)字段前面的逗號(hào)。我也會(huì)在 GROUP BY 子句做同樣的事情。0 可以消除這個(gè)額外的工作。

在新的一行JOIN

將JOIN語(yǔ)句放在一個(gè)新行的優(yōu)勢(shì)包括：

通過(guò)僅僅向下滾動(dòng)JOIN語(yǔ)句列表就可以很容易地查看查詢中所涉及到的所有表。

使用 JOIN，相比將所有表和關(guān)系表達(dá)式都列在 WHERE 語(yǔ)句中，它可以將所有關(guān)系邏輯保持在一個(gè)地方。JOIN 語(yǔ)句也許不可能總是遵循在一行，但至少會(huì)在一個(gè)地方。

注釋掉 JOIN 會(huì)相對(duì)比較容易。在調(diào)試時(shí)，當(dāng)你想知道哪個(gè) JOIN 導(dǎo)致數(shù)據(jù)差異時(shí)，將很有用。

列模式編輯

在處理大量的字段時(shí)，列模式編輯非常方便。下面是我的第一次動(dòng)畫GIF展示，顯示你如何注釋掉所有非聚合字段。在實(shí)踐中我使用

列模式編輯(外部鏈接)，不僅僅是注釋字段還包括:

大量創(chuàng)建索引

在使用 UNION 語(yǔ)句時(shí)帶有長(zhǎng)的字段列表

注 釋GROUP BY 子句長(zhǎng)的字段列表

測(cè)試查詢結(jié)果

我不得不使用外連接來(lái)列出所有客戶，因?yàn)椴⒉皇撬锌蛻舻泥]政編碼在 location 表中都能找到對(duì)應(yīng)郵政編碼。我能夠做到這一點(diǎn)，通過(guò)在我的查詢中反復(fù)包括和排除不同的字段和表，確保我能夠與基于第一原則的最早查詢保持一致。

SELECT

0

,c.cust_post_code

--,p.location

,COUNT(DISTINCT c.cust_id) number_customers

,SUM(s.total_amount) AS total_sales

FROM

customers c

--LEFT OUTER JOIN post_codes p ON c.cust_post_code = p.post_code

JOIN sales s ON c.cust_id = s.cust_id

WHERE

1=1

AND s.sales_date BETWEEN '2015-01-01' AND '2015-01-31'

--AND c.cust_post_code = 2000

--AND p.post_code = 200

GROUP BY

c.cust_post_code

--,p.location

對(duì)我來(lái)說(shuō)，像這樣格式化SQL，意味著我不必編寫為了檢查數(shù)據(jù)做單獨(dú)的測(cè)試。通過(guò)注釋掉一些行，我能使用第一原則來(lái)測(cè)試數(shù)據(jù)的準(zhǔn)確性。這可以提高我的效率，以及報(bào)表的準(zhǔn)確性。

更多信息請(qǐng)查看IT技術(shù)專欄