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

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

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

一

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

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

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

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

二

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

這其實是個胡扯!

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

三

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