【數據蔣堂】第30期：JOIN簡化 - 消除關聯

咱們將等值JOIN分紅三種狀況來分別討論，分狀況至關於增強了條件，咱們能夠充分利用每種狀況下的特徵。

1. 外鍵屬性化

先看個例子，設有以下兩個表：

employee表和delpartment表的主鍵都是其中的id字段，employee表的department字段是指向department表的外鍵，department表的manager字段又是指向employee表的外鍵。這是很常規的表結構設計。

如今咱們想問一下：哪些美國籍員工有一箇中國籍經理？

用SQL寫出來是這樣的：

SELECT A.* FROM employee A JOIN department B ON A.department=B.id JOIN employee C ON B.manager=C.id
 WHERE A.nationality=‘美國' AND C.nationality=‘中國'

句子較長，因爲employee表須要兩次參與JOIN，還須要爲它起個別名加以區分。

咱們換一種寫法：

SELECT * FROM employee WHERE nationality='美國' AND department.manager.nationality='中國'

固然，這不是標準的SQL語句了。

第二個句子中用紅色部分表示當前員工的「所屬部門的經理的國籍」。咱們把外鍵字段理解成一個對象，外鍵表的字段被理解爲外鍵字段的屬性，department.manager便是」所屬部門的經理「，而這個字段在department中仍然是個外鍵，那麼它的外鍵表字段能夠繼續理解爲它的屬性，也就會有department.manager.nationality，即「所屬部門的經理的國籍」。

這種的對象式理解方式，顯然比笛卡爾積過濾的理解方式要天然直觀得多。外鍵表JOIN時並不會涉及到兩個表的乘法，外鍵字段只是用於找到外鍵表中對應的那條記錄，徹底不會涉及到笛卡爾積這種有乘法特性的運算。

咱們前面約定，外鍵表JOIN時維表中關聯字段必須是主鍵，因此外鍵字段對應的維表記錄必定是惟一的，這樣deparment.manager.nationality對於employee表中每一條記錄都是惟一的，這就不會發生歧義。而若是不作這個約定，就可能發生多對多，department.manager.nationality沒法明肯定義。

事實上，這種對象式寫法在結構化高級語言（如C，Java）中很常見，在這類語言中，數據就是按對象方式存儲的。employee表中的department字段取值根本就是一個對象，而不是編號。其實許多表的主鍵取值自己並無業務意義，僅僅是爲了區分記錄，而外鍵字段也僅僅是爲了找到外鍵表中的相應記錄，若是外鍵字段直接是對象，就不須要再經過編號來標識了。不過，SQL缺少離散性，不能直接使用這種存儲機制，還要藉助編號。

外鍵表關係中，事實表和維表是不對等的，只能基於事實表去找維表字段，而不會有倒過來的狀況。

2. 同維表等同化

同維表的狀況相對簡單，仍是從例子開始，設有兩個表：

兩個表的主鍵都是id，經理也是員工，兩表共用一樣的員工編號，經理會比普通員多一些屬性，另用一個經理表來保存。

如今咱們要統計全部員工（包括經理）的總收入（加上津貼）。

用SQL寫出來仍是會用到JOIN：

 

SELECT employee.id, employee.name, employy.salary+manager.allowance FROM
 employyee LEFT JOIN manager ON employee.id=manager.id

 

而對於兩個一對一的表，咱們其實能夠簡單地把它們當作一個表：

 

SELECT id,name,salary+allowance FROM employee

 

一樣地，根據咱們的約定，同維表JOIN時兩個表都是按主鍵關聯的，相應記錄是惟一對應的，salary+allowance對employee表中每條記錄都是惟一可計算的，不會出現歧義。

同維表之間的關係是對等的，從任何一個表均可以引用到其它同維表的字段。

3. 主子表一體化

訂單及訂單明細是典型的主子表：

Orders表的主鍵是id，OrderDetail表中的主鍵是(id,no)，前者的主鍵是後者的一部分。

如今咱們想計算每張訂單的總金額。

直接用SQL寫出來會是這樣：

 

SELECT Orders.id, Orders.customer, SUM(OrderDetail.price)
 FROM Orders JOIN OrderDetail ON Orders.id=OrderDetail.id
 GROUP BY Orders.id, Orders.customer

 

要完成這個運算，不只要用到JOIN，還須要作一次GROUP BY，不然選出來的記錄數太多。

若是咱們把子表中與主表相關的記錄當作主表的一個字段，那麼這個問題也能夠再也不使用JOIN以及GROUP BY：

SELECT id, customer, OrderDetail.SUM(price) FROM Orders

與普通字段不一樣，OrderDetail被當作Orders表的字段時，其取值將是一個集合，由於兩個表是一對多的關係。因此要在這裏使用聚合運算把集合值計算成單值。

這樣看待數據關聯，不只理解書寫更爲簡單，並且不容易出錯。

假如Orders表還有一個子表用於記錄回款狀況：

咱們如今想知道那些訂單還在欠錢，也就是累計回款金額小於訂單總金額的訂單。

簡單地把這三個表JOIN起來是不對的，OrderDetail和OrderPayment會發生多對多的關係，這就錯了（回憶上一篇中多對多大機率錯誤的說法）。這兩個子表要分別先作GROUP，再一塊兒與Orders表JOIN起來才能獲得正確結果，寫出來較爲繁瑣。

而若是咱們把子表當作主表的集合字段，那就很簡單了：

SELECT id,customer,OrderDetail.SUM(price) x, OrderPayment.SUM(amount) y FROM Orders WHERE x>y

這種寫法就不容易發生多對多的錯誤。

主子表關係是不對等的，不過兩個方向的引用都有意義，上面談了從主表引用子表的狀況，從子表引用主表則和外鍵表相似。

咱們改變對JOIN運算的見解，摒棄笛卡爾積的思路，把多表關聯運算當作是稍複雜些的單表運算。這樣，咱們至關於從最多見的等值JOIN運算中基本消除了關聯，甚至在語法中取消了JOIN關鍵字，書寫和理解都要簡單不少。

我有幾張阿里雲幸運券分享給你，用券購買或者升級阿里雲相應產品會有特惠驚喜哦！把想要買的產品的幸運券都領走吧！快下手，立刻就要搶光了。

https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=n7gh3gne&utm_source=n7gh3gne