我們知道，SQL長得很像英語，簡單的SQL語句直接可以作為英語讀。除了SQL外，其它主要程序設(shè)計語言都沒有這樣，語法中就算有英語單詞也僅僅是作為某些概念或操作的助記符而已，寫出來的是形式化的程序語句(statement)而不是英語句子(sentence)。而SQL不同，它會把整個句子寫成符合英語習(xí)慣的形式，還會補(bǔ)充很多不必要的介詞，比如FROM作為語句的運算主體卻被寫到后面，GROUP后面要寫一個多余的BY。

為什么會這樣?很容易想到的理由是希望非程序設(shè)計人員也能使用。用戶只要會讀寫英語，就可以寫出SQL來查詢數(shù)據(jù)。這顯然是個善意的初衷，但結(jié)果卻不盡如人意。絕大多數(shù)業(yè)務(wù)人員只會用SQL寫非常簡單的查詢，而對于這類查詢，應(yīng)用程序常常都有更為便捷直觀的可視化界面來協(xié)助，并不需要直接手寫語句，這個設(shè)計初衷就失去意義。反過來， 經(jīng)常使用SQL做運算的仍然是程序員，SQL還是一種編程語言，像不像英語對于程序員理解并沒有多大差別，反而會帶來不小的困難。

事實上，SQL是一種語法非常嚴(yán)格的語言，語句中任何一點不合規(guī)的地方就會被解釋器拒絕，使用者必須認(rèn)真學(xué)習(xí)并遵守其語法規(guī)則，這和其它程序設(shè)計語言并沒什么兩樣。而自然語言真正的優(yōu)勢在于具有模糊性，可以一定程度接受不嚴(yán)格的語法，但SQL并沒有支持這一點，在發(fā)明SQL那個年代也實現(xiàn)不了這個特性。

一

像英語的好處沒有體現(xiàn)，壞處卻很嚴(yán)重，將語法設(shè)計得像自然語言，看起來容易掌握，其實恰恰相反。

貼近自然語言帶來的主要壞處是非過程性。程序邏輯一般是分步執(zhí)行的，用變量記錄中間結(jié)果，供后面的步驟使用。但自然語言不是這樣，兩句話之間的引用關(guān)系靠少量幾個代詞維系，不夠用且不精確，所以更習(xí)慣的做法是把盡量多的任務(wù)寫在一句話中，復(fù)雜情況下就會大量使用從句。在SQL中的表現(xiàn)就是一句話中配有多個動作，SELECT、WHERE、GROUP都拼進(jìn)去，像WHERE和HAVING其實是一個意思，卻要采用兩個詞以示區(qū)別，而查詢需求復(fù)雜時就會出現(xiàn)多層嵌套的子查詢。這種現(xiàn)象在其它程序設(shè)計語中是不常見的。

分步是降低理解和執(zhí)行難度的有效法門，本來挺簡單分幾步能做到的事情，如果不分步就會很繞。比如要找出銷售額超過平均值兩倍的客戶，自然思維方式就是先算出銷售額的平均值，再找出銷售額超這個值兩倍的客戶，兩個語句完成。而SQL的寫法就需要用子查詢寫成更長的一句。這個例子還算好懂，只有兩層，一般自然語言的從句用來描述兩層關(guān)系的理解難度還可以接受，但實際復(fù)雜的查詢涉及到三五層的比比皆是，嚴(yán)重增加理解難度。

不提倡分步，就會導(dǎo)致單句SQL很長。程序員面臨的復(fù)雜SQL語句，很少以行計，經(jīng)常是以K計。而同樣的100行代碼，分成100個語句還是只有1個語句，其復(fù)雜度完全不是一個層面的。這種代碼理解起來非常困難，好不容易寫出來，過兩個月后自己都讀不懂，而且太長不分步的單句非常難以調(diào)試，開發(fā)周期也更長。

二

關(guān)于過程性，SQL的擁躉者一直有一個說法：寫SQL時用戶只要關(guān)心要什么，而不必關(guān)心怎么做，計算機(jī)會自動找解決方案，這樣語法本身不需要支持過程性。

這其實是個胡扯!

任何程序語言在某種層次上都具有這個能力，寫匯編語言需要關(guān)心寄存器和內(nèi)存的動作，但不必關(guān)心更下層的與非門的動作。SQL中不必關(guān)心數(shù)據(jù)在物理存儲層面(文件系統(tǒng)、內(nèi)存和硬盤)的動作，但仍然要關(guān)心邏輯層面(表和字段)的運算。SQL語句事實上也在描述運算邏輯，特別是多層嵌套關(guān)聯(lián)的復(fù)雜SQL，在描述問題目標(biāo)的同時，實際上也指明了執(zhí)行過程，或者倒過來說，在SQL中也只能用指明執(zhí)行過程的方法來描述問題目標(biāo)，只不過相對比較高層次一些而已。

三

不過，SQL只是不提倡分步計算，而并非完全不支持過程性。使用存儲過程就相當(dāng)于分步執(zhí)行SQL，使用外部程序調(diào)用SQL也可以實現(xiàn)過程性，如果不考慮臨時表(用于存儲中間結(jié)果)和數(shù)據(jù)庫IO(外部語言調(diào)用SQL時要獲得運算結(jié)果)的低性能，這些方法在功能上并沒什么缺失。但要考慮到數(shù)據(jù)量導(dǎo)致的性能問題時，還是經(jīng)常需要編寫長SQL才能解決問題。在數(shù)據(jù)量較小、性能問題不突出時，可以用這些方法來補(bǔ)充SQL的過程性。