第20期：從SQL語法看離散性
所謂離散性，是指集合的成員可以游離在集合之外存在并參與運算，游離成員還可以再組成新的集合。從離散性的解釋上可以知道，離散性是針對集合而言的一種能力，離開集合概念單獨談離散性就沒有意義了。
離散性是個很簡單的特性，幾乎所有支持結構(對象)的高級語言都天然支持，比如我們用Java時都可以把數組成員取出來單獨計算，也可以再次組成新的數組進行集合運算(不過Java幾乎沒有提供集合運算類庫)。
但是SQL的離散性卻很差。
SQL體系中有記錄的概念，但并沒有顯式的記錄數據類型。單條記錄被SQL作為只有一條記錄的臨時表處理，也就是個單成員的集合。而且，SQL從表(集合)中取出記錄時總是復制出一條新記錄，和原表中的記錄已經沒有關系了，這個特性被稱為immutable。immutable特性有助于保證代碼的正確性和簡單性，但也會喪失離散性。
一
缺失離散性會帶來代碼的繁瑣和效率的低下。
比如要計算張三和李四的年齡差和工資差，SQL要寫成兩句：
- SELECT (SELECT age FROM employee WHERE name='張三') - ( SELECT age FROM employee WHERE name='李四') FROM dual
- SELECT (SELECT salary FROM employee WHERE name='張三') - ( SELECT salary FROM employee WHERE name='李四') FROM dual
這不僅書寫麻煩，而且要重復查詢。
如果支持較好的離散性，我們可以寫成這樣：
- a = employee.select@1(name="張三")
- b = employee.select@1(name="李四")
- aagediff=a.age-b.age
- salarydiff=a.salary-b.salary
查詢結果可以游離在集合外獨立存在，并可以反復使用。
二
immutable特性會要求每次運算都復制數據，這在只讀的運算中還只是浪費時間和空間影響效率，但如果要改寫數據時，造成的麻煩就嚴重得多。
比如我們想對業績在前10%銷售員再給予5%的獎勵。一個正常思路是先把業績在前10%的銷售員找出來，形成一個中間集合，然后再針對這個集合的成員執行獎勵5%的動作。但由于SQL缺乏離散性，immutable特性導致滿足條件的記錄再形成的集合和原記錄是無關的，在中間結果集上做修改沒有意義。這樣就迫使我們要把整個動作寫成一個語句，直接在原表中找到滿足條件的記錄再加以修改，而前10%這種條件并不容易簡單地在WHERE子句中寫出來，這又會導致復雜的子查詢。這還只是個簡單例子，現實應用中比這復雜的條件比比皆是，用子查詢也很難寫出，經常采用的辦法則是先把滿足條件的記錄的主鍵計算出來，再用這些主鍵到原表中遍歷找到原記錄去修改，代碼繁瑣且效率極為低下。
如果語言支持離散性，我們就可以執行上述思路了：
- a=sales.sort@z(amount).to(sales.len()*0.1) //取出前業績在10%的記錄構成一個新集合
- a.run(amountamount=amount*1.05) //針對集合成員執行獎勵5%動作
三
從上面兩個簡單例子可以看出，缺失離散性會加劇分步計算的困難，immutable特性會降低性能并占用空間。當然，離散性的問題還不止于此。
不能用原集合的成員構成新集合再進行計算，SQL在做分組時無法保持分組子集，必須強迫聚合，作為集合化語言，SQL的集合化并不徹底。沒有游離記錄及其集合的表示方法，只能用傳統的外鍵方案表示數據之間的關聯關系，寫出的代碼即繁瑣又難懂，而且運算性能還差，缺乏離散性的SQL無法采用直觀的引用機制描述關聯。特別地，沒有離散性的支持，SQL很難描述有序計算，有序計算是離散性和集合化的典型結合產物，成員的次序在集合中才有意義，這要求集合化，有序計算時又要將每個成員與相鄰成員區分開，會強調離散性。
這些具體內容我們會在后續文檔中逐步詳細說明。我們要從理論上改進SQL(或者更合適的說法是關系代數)，主要工作就是在保持集合化的基礎上引入離散性，從而解決上述問題，讓新的語言能夠同時擁有SQL和Java的優點。
