本次学习内容为集合运算和表的连接，作为一个sql老鸟，这次的内容并没有十分困难，但是其中有一些说法是我没有接触过的。
1.bag模型和set模型
作为一个数学系的人，可以说是天天与集合在打交道，而Bag和Set与数据库之间的关系，确是我从来没有接触过的（确实是浅薄了）。
在高中数学课上我们就学过, 集合的一个显著的特征就是集合中的元素都是互异的. 当我们把数据库中的表看作是集合的时候, 实际上存在一些问题的: 不论是有意的设计或无意的过失, 很多数据库中的表包含了重复的行.
Bag 是和 set 类似的一种数学结构, 不一样的地方在于: bag 里面允许存在重复元素, 如果同一个元素被加入多次, 则袋子里就有多个该元素.
通过上述 bag 与 set 定义之间的差别我们就发现, 使用 bag 模型来描述数据库中的表在很多时候更加合适.
是否允许元素重复导致了 set 和 bag 的并交差等运算都存在一些区别. 以 bag 的交为例, 由于 bag 允许元素重复出现, 对于两个 bag, 他们的并运算会按照: 1.该元素是否至少在一个 bag 里出现过, 2.该元素在两个 bag 中的最大出现次数 这两个方面来进行计算. 因此对于 A = {1,1,1,2,3,5,7}, B = {1,1,2,2,4,6,8} 两个 bag, 它们的并就等于 {1,1,1,2,2,3,4,5,6,7,8}。对于两个 bag, 他们的交运算会按照: 1.该元素是否同时属于两个 bag, 2.该元素在两个 bag 中的最小出现次数这两个方面来进行计算. 因此对于 A = {1,1,1,2,3,5,7}, B = {1,1,2,2,4,6,8} 两个 bag, 它们的交运算结果就等于 {1,1,2}。
由于我没有想到更好的表述方式，现在全部摘录如上，从这个方面来理解数据库的集合运算，的确是一个非常好的切入点。
关于JOIN
对于数据库来说，JOIN是一个极为常用的操作，可以说有SELECT的地方就有JOIN，因为在实际场景中几乎没有任何数据是独立存在的，尤其是在这个数据量高速膨胀的时代。
但是，我们必须知道，JOIN是一个较为耗费资源的操作，这是因为在进行JOIN的过程中，不可避免地会进行一系列的比较。而这些比较落在计算机上，就是一次次地移动磁头。如果数据量少的话自然是无所谓，但是如果数据量较大，这样的资源耗费就会是十分巨大的。
而提起比较，最为直接的想法就是将“比较”这个操作建立在有索引的列上，这样也可以通过索引来进行比较，从而减少磁头的移动次数，继而达到节约资源的目的。
--------剩下的之后补。。。。。。。。
