数据库设计和优化

1.      主键&外键

键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。

首先来谈：主键。

关系数据库依赖于主键—它是数据库物理模式的基石。主键在物理层面上只有两个用途：

1. 惟一地标识一行。一般用id来标示。

2. 作为一个可以被外键有效引用的对象。

基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：

1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。

2. 主键应该是单列的，以便提高连接和筛选操作的效率。

注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数 据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键， 即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表 主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。

3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。

外键：是用来和其他表建立联系用的：这个表中的一列和另外一个表中的一列相同，为了让这两个表联系起来，就把其中一个表中的列设成外键，把另外一个表列设成主键，就实现了这两个表的关联。

ps：一个表可以有多个外键。但主键只能有一个。

设计SQL表的时候，外键P相当于有个约束。即：如果外键作为主键的表（P）还没有数据，那么你对当前表（主键A，外键P的这张表）进行相关操作会报错的。

如果没必要进行强关联，进行建表的时候也可以不必设为外键，只要你自己知道有这个键就行。

 

2.      要善于识别与正确处理多对多等关系 

一个实体转换为一个关系模式。

实体的属性就是关系的属性，实体的标识符就是关系的关键字。

实体间联系的转换有以下几种：

1：1

1：n

m：n

常用的转换方法举例：

 

意思就是用一张表，里面包含部门和部门经理的信息。

可以看到：如果需要插入部门表的信息，那么经理表中一定要存在这条数据。这就是外键约束。

 

 

 

设计原则：http://www.cnblogs.com/happylsc/archive/2010/09/01/1814682.html

 

 

3.      数据模型的优化

有了关系模型，可以进一步优化，方法为： 

　　（1） 确定数据依赖。 

　　（2） 对数据依赖进行极小化处理，消除冗余联系（参看范式理论）。 

　　（3） 确定范式级别，根据应用环境，对某些模式进行合并或分解。 

　　以上工作理论性比较强，主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了： 

　　（4） 对关系模式进行必要的分解。 

　　如果一个关系模式的属性特别多，就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的，而有些属性是很少访问的，则应该把它们分解为两个关系模式。 

如果一个关系的数据量特别大，就应该考 虑是否可以进行水平分解。如一个论坛中，如果设计时把会员发的主贴和跟贴设计为一个关系，则在帖子量非常大的情况下，这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的，而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件，可以考虑按省份或其它方式进行水平分解。

 

概念设计的必要性：http://www.bsuc.cn:8013/wlkc/db/section6/6.3.html

MySQL表的优化：http://teny32.blog.51cto.com/8027509/1336169

http://linux.chinaitlab.com/MYSQL/907310.html

MySQL优化总结：http://blog.chinaunix.net/uid-20639775-id-3154234.html