《高性能的数据库》第一讲：范式设计

 
第一讲：范式设计

 

首先，俺说，数据库重在设计，然后才是开发。按照第三范式开发，会让你提升到一个新的境界！

名词解释：第三范式

第一范式：一个不包含重复列的表归于第一范式。 

第二范式：如果一个表归于第一范式且只包含依赖于主键的列，则归于第二范式。 

第三范式：如果一个表归于第二范式且只包含那些非传递性地依赖于主键的列，则归于第三范式。 

简单解释：

第一范式：不设计重复字段的表

比如：
Create Table tb1 ( 
  fd1 varchar(20),  --用来存放电话
  fd2 varchar(20),  --用来存放电话
  fd3 int           --其他
)

则fd1,fd2违反第一范式

第二范式:

第二范式：不设计没有主键，或没有唯一索引的表

比如：如果一个表存在相同的数据，那必然是违反第二范式无疑。

第三范式：能细分则细分每个字段。

比如：一个表，原来设计为：

Create TAble Clothes( 
  ClothesID int primary key,--ID
  Color     varchar(10),     --颜色
  Description varchar(20)    --描述
)

那么Color违反了第三范式

于是,第三范式应该这样设计

Create TAble Clothes( 
  ClothesID int primary key,--ID
  ColorID     Int,     --颜色ID
  Description varchar(20)    --描述
)

Create Table Color(
  ColorID int primary key,
  Color  varchar(20)
)

Color作为主表,Clothes作为子表,两者用ColorID互联.

三范式设计的好处：减少数据冗余，提高系统可维护性，提高系统可扩展性。
三范式设计的缺点：会降低数据库的性能。（嘻嘻，不过非常少，大家放心）

基于网络的考虑

　　数据库的规范化提高了系统性能，但不是单纯为了规范化而规范化，高范式等级的数据库在网络中不一定有高性能。因为使数据库规范化的方法是把表拆分成相关列最少的表，这样查询时就需要用复杂的联结，占用较多的CPU资源和I/O操作，才能查到客户端所需的数据。这样的开销是我们所不希望的，因为这会导致复杂度的增加和性能的下降。所以在网络环境下有必要对规范化进行必要的平衡，使系统有最优的性能。提高数据库的网络性能，在系统中我们采用了下面的方法。

适量增加冗余

　　非网络的集中式数据库中要尽可能减少数据的冗余度，以节省存贮空间，使数据易于保持一致性。冗余数据虽易造成不一致性，且系统为了维护冗余数据要付出一定的代价，但在网络数据库中适当增加数据的冗余是有好处的。增加冗余分两个层次：一是数据库层，二是表层。

　　数据库层数据冗余：系统建模无论采用何种体系结构，冗余数据可以数据副本的方式出现，副本的存在使许多应用可以"本地性"，大大减少了网络通信，提高了系统的性能；再有当某一结点出现故障时，由于拷贝副本的存在，系统仍可对此副本操作，而不至于因一处故障而使系统无法使用。

　　表层数据冗余：数据库的规范化其实质是概念的单一化，所以规范后的数据库中的表一般都较小，使表中相关列最少，这虽然增强了数据库的可维护性，但在系统要完成一些检索时，可能要用复杂的联结才能实现。这种操作有时需要网络I/O上的较大开销，这将导致性能的下降。对这一问题的解决方案，一是建立临时表或定义视图以减少频繁出现的多表联结，二是在数据库的设计时仅采用恰当的范式等级。

增加标识列

　　当一个表需要多个列的组合才能组成主键时，可以在表中合理的增加一列作为主键，唯一标识此表，一般这一列用的值是一个编号或是时间戳(timestamp)等。在这种情况下增加列虽然多占了存贮空间，但是在索引中以此列代替大的组合键，从而获得了性能的提高。

大表横向分割

　　在执行查询时如果只涉及一大表的一个子集，可以把这个大表分成多个表，也即对表进行了分割，可提高在网络环境下的查询速度。

结束语

　　在基于网络的数据库设计过程中，既要考虑其范式要求，也要考虑其网络要求。当在这两者之间有冲突时,要在两者之间作一个平衡，根据实际应用进行具体的系统分析，权衡各方面的因素后，选择最优设计方案