1.8. 数据库应用¶
1.8.1. 常见的四种数据库设计模式¶
1.8.1.1. 主扩展模式：¶
一般应用于提取不同类型的对象的共同特征。比如学校当中，对于上课而言分为老师和学生，但对于食堂大妈或者门卫大爷而言，就看你是不是校内人员。这是一种包含关系。即校内人员包括 学生、老师、其他工作人员。如果做一个签到系统，就设定校内人员为user表，老师、学生之类的单独成表，但是都维护同样的userid同时作为二者的主键。使之成为1对1的关系。这种模式就是主扩展模式。
扩展表的主键既是扩展表的主键也是主表的外键
主扩展模式通常用来将几个相似的对象的共有属性抽取出来，形成一个”公共属性表“，且“公共属性表”与“专有属性表”是“一对一”的关系。
“专有属性表”可以看做是“公共属性表”的 扩展，两者合在一起就是对一个特定对象的完整描述，故此得名“主扩展模式”。对象的个数不多；各个对象之间的属性有一定差别；各个对象的属性在数据库设计阶段能够完全确定；各个扩展对象有独立的、相对比较复杂的业务处理需求，此时用“主扩展模式”。将各个对象的共有属性抽取出来设计为“主表”，将各个对象的剩余属性分别设计为相应的“扩展表”，“主表”与各个“扩展表”分别建立一对一的关系。
1.8.1.2. 主从模式¶
主从模式，是数据库设计模式中最常见，也是大家日常设计工作中用的最多的一种模式，他描述了两个表之间的主从关系，是典型的一对多关系。对象的个数较多且不固定；各个对象之间的属性几乎没有差异；对象的属性在数据库设计阶段能够完全确定；各个对象没有独立的业务处理需求，此时用“主从模式”。将各个对象设计为“从表”的记录，与“主表”对象建立一对多的关系。是典型的一对多的关系。比如贴吧的实现，整个吧就是一个主表。而贴吧有许多的从表就是不同楼主发的帖子，而每个帖子又有很多从表那就是每个楼所对应的信息。
1.8.1.3. 名值关系¶
主要处理系统设计阶段还不能完全确定的属性的对象。这些对象的属性在系统运行时会有很大的变更，或者是多个对象之间的属性存在很大的差异。比如说一个学生的表，记录了一些学生必须有的属性：年龄身高体重姓名什么的。但是突然有一天有一个人穿越了，他就需要一个剑术值的数据。通常需要额外两个表来存储这种不确定是否会用会有的属性。
首先需要一个属性模版表，就是不管这个属性属于谁，属于何物，何时，我只是证明有这么一条额外属性而存在。那么上述的例子当中，属性模板表当中就需要添加一条属性：（属性代码一般给属性分类用）
ID 1 属性代码 1001 属性名称 剑术值
但是具体剑术值是多少，这个表不去讨论。存储数据的表称为额外属性表，这个表存储的字段分别标识:
这条数据属于哪个人、物（角色id）
这条数据是什么属性 （属性模板ID）
属性的具体值是多少（data)
1.8.1.4. 多对多关系¶
多对多模式，也是比较常见的一种数据库设计模式，它所描述的两个对象不分主次、地位对等、互为一对多的关系。对于A表来说，一条记录对应着B表的多条记录，反过来对于B表来说，一条记录也对应着A表的多条记录，这种情况就是“多对多模式”。多对多模式需要在两个表之间有一个关联表，这个关联表也是―多对多模式的核心所在。根据关联表是否有独立的业务处理需求，可将其划分为两种细分情况。 取决于关联表有没有业务需求。
关联表有独立的业务处理需求。
比如网上书店，通常都会有―书目信息和―批发单。一条―书目信息面对不同的购买客户、可以存在多张―批发单，反过来，一张批发单也可以批发多条书目，这就是多对多模式。中间的批发单明细表就是两者的关联表，具备独立的业务处理需求，是一个业务实体对象，因此它具备一些特有的属性，比如针对每一条明细记录而言的累计退货次数、累计退货数量、累计结算次数、累计结算数量；由于批发单明细在数据产生后已经打印出纸质清单提供给客户，因此在批发单明细表里对纸质清单中打印的书目信息属性作了冗余（逆标准化），这样在将来即使修改了―书目信息表中的属性，也不会影响跟客户核对批发单明细，不会影响未来的财务结算业务。
关联表没有独立的业务处理需求。
比如用户与角色之间的关系，一般系统在做权限控制方面的程序时都会涉及到系统用户表和系统角色表。一个用户可以从属于多个角色，反过来一个角色里面也可以包含多个用户，两者也是典型的多对多关系。其中的关联表用户角色关联表在绝大多数情况下都是仅仅用作表示用户与角色之间的关联关系，本身不具备独立的业务处理需求，所以也就没有什么特殊的属性。