【数据蒋堂】第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