数据库中父表和子表

好久没有碰数据库分析设计了。今天突然要做一个数据库分析，很是费解，所谓好记性不如烂笔头，个人觉得还是要记一下的。用一个例子来说：

你想要设计的一个产品表可能是这样的：

产品表：产品ID， 产品名称， 产品类型

 产品ID   产品名称        产品类型
  1        敌敌畏          农药
  2        加多宝          饮料  
  3        可乐           饮料

那么，接下来我们把这个产品表拆分开来（实际开发中），因为在数据库设计中除了外键以外其他字段是不可以重复的（产生冗余），因为不可能你一个界面就设计一张表，你需要分析这样一对多的关系，便于管理维护：

产品表：产品ID，产品名称，产品类型ID

产品类型表：产品类型ID，产品类型名称

产品ID  产品名称  产品类型ID
  1     敌敌畏     1
  2     加多宝     2
  3     可乐       2

产品类型ID   产品类型名称
   1           农药
   2           饮料

相信大家对于这样的拆分是可以理解的，因为一个产品类型对应多个产品，是一对多的关系，所以我们把这个产品类型表的主键放到产品表中做外键，形成主外键的关联，那么产品表相当于继承了产品类型表的东西，继承，那么大家可以联想到的就是儿子继承父亲的东西，所以产品表是子表，产品类型表是父表。也有一种说法是主表和从表的说法。

还有一种比较棘手的数据库设计模式就是多对多的关系：

学生表：学生ID，学生名称。。。

选课表：课程ID，课程名称。。。

学生_选课表：学生选课ID，学生ID，选课ID。。。

上面的例子中可以这么理解，一个学生对应多个课程，而一个课程也可以对应多个课程，两个一对多的关系，加外键也是搞不定了。所以这个时候我们就可以引入一个中间表（关系表），学生_选课表进行逻辑的处理，而且不破坏学生表和选课表的结构关系。这样，我们如果想要查出一个学生的所有选课，或者一个选课的所有学生，就可以通过联表查询查出想要的结果了。奥耶

比较常用的有递归表：

可能你想要的是这种效果，但是对于地区名称这个字段中还可以细分，因为广东属于中国，广州属于广东，存在这样的关系。。。。

地区表：地区ID，地区名称
         1     中国
         2     广东
         3     广州

我们引入一个地区ID_f就是地区ID的父亲，建立递归关系。

地区表：地区ID，地区名称，地区ID_f
         1     中国     0
         2     广东     1
         3     广州     2
         4     浙江     0

个人觉得你在数据库表的设计上如果碰到类似这样的表结构，我们还可以引入属性表的概念：

颜色表：颜色ID，颜色

尺寸表：尺寸ID，尺寸

地区表：地区ID，地区名称

等等

大家看，这些表的结构是不是相识，只有一个ID外加一个字段。

那么，我们可以引入属性集合表和属性集合明细表的概念来优化

属性集合表：属性集合ID,属性集合名称
             1        颜色
             2        尺寸
             3        地区


属性集合明细表：属性集合明细ID，属性集合ID，属性集合明细名称
               1            1           红色
               2            1           绿色
               3            2           大
               4            3           中国
               5            3           美国

需要注意的是，我们需要记住属性集合的ID，这样比较方便，我们在使用前可以对属性集合ID进行一个判断，如果是1，则判断颜色。