我們將等值JOIN分成三種情況來分別討論，分情況相當(dāng)于加強(qiáng)了條件，我們可以充分利用每種情況下的特征。

1. 外鍵屬性化

先看個(gè)例子，設(shè)有如下兩個(gè)表：

employee表和delpartment表的主鍵都是其中的id字段，employee表的department字段是指向department表的外鍵，department表的manager字段又是指向employee表的外鍵。這是很常規(guī)的表結(jié)構(gòu)設(shè)計(jì)。

現(xiàn)在我們想問一下：哪些美國籍員工有一個(gè)中國籍經(jīng)理?

用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，還需要為它起個(gè)別名加以區(qū)分。

我們換一種寫法：

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

當(dāng)然，這不是標(biāo)準(zhǔn)的SQL語句了。

第二個(gè)句子中用紅色部分表示當(dāng)前員工的“所屬部門的經(jīng)理的國籍”。我們把外鍵字段理解成一個(gè)對象，外鍵表的字段被理解為外鍵字段的屬性，department.manager即是”所屬部門的經(jīng)理“，而這個(gè)字段在department中仍然是個(gè)外鍵，那么它的外鍵表字段可以繼續(xù)理解為它的屬性，也就會有department.manager.nationality，即“所屬部門的經(jīng)理的國籍”。

這種的對象式理解方式，顯然比笛卡爾積過濾的理解方式要自然直觀得多。外鍵表JOIN時(shí)并不會涉及到兩個(gè)表的乘法，外鍵字段只是用于找到外鍵表中對應(yīng)的那條記錄，完全不會涉及到笛卡爾積這種有乘法特性的運(yùn)算。

我們前面約定，外鍵表JOIN時(shí)維表中關(guān)聯(lián)字段必須是主鍵，所以外鍵字段對應(yīng)的維表記錄一定是***的，這樣deparment.manager.nationality對于employee表中每一條記錄都是***的，這就不會發(fā)生歧義。而如果不做這個(gè)約定，就可能發(fā)生多對多，department.manager.nationality無法明確定義。

事實(shí)上，這種對象式寫法在結(jié)構(gòu)化高級語言(如C，Java)中很常見，在這類語言中，數(shù)據(jù)就是按對象方式存儲的。employee表中的department字段取值根本就是一個(gè)對象，而不是編號。其實(shí)許多表的主鍵取值本身并沒有業(yè)務(wù)意義，僅僅是為了區(qū)分記錄，而外鍵字段也僅僅是為了找到外鍵表中的相應(yīng)記錄，如果外鍵字段直接是對象，就不需要再通過編號來標(biāo)識了。不過，SQL缺乏離散性，不能直接使用這種存儲機(jī)制，還要借助編號。

外鍵表關(guān)系中，事實(shí)表和維表是不對等的，只能基于事實(shí)表去找維表字段，而不會有倒過來的情況。

2. 同維表等同化

同維表的情況相對簡單，還是從例子開始，設(shè)有兩個(gè)表：

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

現(xiàn)在我們要統(tǒng)計(jì)所有員工(包括經(jīng)理)的總收入(加上津貼)。

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

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

而對于兩個(gè)一對一的表，我們其實(shí)可以簡單地把它們看成一個(gè)表：

SELECT id,name,salary+allowance FROM employee 

同樣地，根據(jù)我們的約定，同維表JOIN時(shí)兩個(gè)表都是按主鍵關(guān)聯(lián)的，相應(yīng)記錄是***對應(yīng)的，salary+allowance對employee表中每條記錄都是***可計(jì)算的，不會出現(xiàn)歧義。

同維表之間的關(guān)系是對等的，從任何一個(gè)表都可以引用到其它同維表的字段。

3. 主子表一體化

訂單及訂單明細(xì)是典型的主子表：

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

現(xiàn)在我們想計(jì)算每張訂單的總金額。

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

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

要完成這個(gè)運(yùn)算，不僅要用到JOIN，還需要做一次GROUP BY，否則選出來的記錄數(shù)太多。

如果我們把子表中與主表相關(guān)的記錄看成主表的一個(gè)字段，那么這個(gè)問題也可以不再使用JOIN以及GROUP BY：

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

與普通字段不同，OrderDetail被看成Orders表的字段時(shí)，其取值將是一個(gè)集合，因?yàn)閮蓚€(gè)表是一對多的關(guān)系。所以要在這里使用聚合運(yùn)算把集合值計(jì)算成單值。

這樣看待數(shù)據(jù)關(guān)聯(lián)，不僅理解書寫更為簡單，而且不容易出錯(cuò)。

假如Orders表還有一個(gè)子表用于記錄回款情況：

我們現(xiàn)在想知道那些訂單還在欠錢，也就是累計(jì)回款金額小于訂單總金額的訂單。

簡單地把這三個(gè)表JOIN起來是不對的，OrderDetail和OrderPayment會發(fā)生多對多的關(guān)系，這就錯(cuò)了(回憶上一篇中多對多大概率錯(cuò)誤的說法)。這兩個(gè)子表要分別先做GROUP，再一起與Orders表JOIN起來才能得到正確結(jié)果，寫出來較為繁瑣。

而如果我們把子表看成主表的集合字段，那就很簡單了：

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

這種寫法就不容易發(fā)生多對多的錯(cuò)誤。

主子表關(guān)系是不對等的，不過兩個(gè)方向的引用都有意義，上面談了從主表引用子表的情況，從子表引用主表則和外鍵表類似。

我們改變對JOIN運(yùn)算的看法，摒棄笛卡爾積的思路，把多表關(guān)聯(lián)運(yùn)算看成是稍復(fù)雜些的單表運(yùn)算。這樣，我們相當(dāng)于從最常見的等值JOIN運(yùn)算中基本消除了關(guān)聯(lián)，甚至在語法中取消了JOIN關(guān)鍵字，書寫和理解都要簡單很多。