数据库设计

数据库设计包含需求设计、逻辑设计、物理设计和维护优化。

需求分析：全面了解产品设计的存储需求（存储需求，数据处理需求，数据的安全性和完整性）
逻辑设计：设计数据的逻辑存储结构（数据实体之间的逻辑关系，解决数据冗余和数据维护异常）
物理设计：根据所使用的数据库特点进行表结构设计
维护优化：根据实际情况对索引、存储结构等进行优化

数据库结构优化的目的

减少数据冗余
尽量你变数据维护中出现更新，插入和删除异常
简约数据库的存储空间
提高查询效率

为了设计出没有数据冗余和数据维护异常的数据结构，我们需要遵循以下规范：

第一范式

数据库表中的所有字段都只有单一属性
单一属性的列都是由基本的数据类型所构成
设计出来的表都是简单的二维表

第二范式
要求一个表中只具有一个业务主键，也就是说符合第二范式的表中不能存在非主键列对只对部分主键的依赖关系。以学生选课为例，它的主键是复合主键（学生编号，课程），而学分只依赖于课程，即非主键列只对部分主键存在依赖关系，不符合第二范式。
image.png

针对这个问题，我们怎么破呢？我们对上面这个表拆分为3个表：学生表、课程表、学生课程关系表。其中，学生表和课程表只有一个主键，而学生课程关系表有一个复合主键（学生编号，课程），分数完全依赖于这个复合主键，因此符合第二范式。

image.png

第三范式

每一个非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主属性对主键的传递依赖。
对于学生表，学院依赖于学生编号，而学院地址却依赖于学院，这就是传递依赖，此时，这张表不满足第三范式。如果想让这张表满足第三范式就需要继续对这张表进行拆分。

image.png

反范式化

遵循范式化的数据库设计，实现了消除数据冗余的目的，但是此时数据库的性能和读取效率并不是最优的。为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违反，而允许存在少量的数据冗余，换句话来说反范式化就是使用空间来换取时间。
举个栗子，以我们经常进行下单为例。根据范式准则，定单表和订单商品关联表如下：

订单表：{订单编号，下单用户名，下单日期，支付金额，物流单号}
订单商品关联表：{订单编号，订单商品分类，订单商品名，商品数量}

我们知道查询订单时，往往需要知道用户名称和用户手机号，那么，此时我们就需要将订单表和用户表进行关联查询。这种设计存在一个问题，当用户修改手机号，那么用旧手机号买的订单号的手机信息是新的手机号，而不是旧手机号，这是不符合业务需求的。解决这个问题的办法就是将用户名和用户手机号加入到订单表中。同样情况，商品的价格也存在修改的情况，因此，也需要将支付金额加入到订单表中，此时，订单表和订单商品关联表如下：

订单表：{订单编号，下单用户名，下单日期，支付金额，物流单号，订单金额}
订单商品关联表：{订单编号，订单商品分类，订单商品名，商品数量，商品单价}

总结

范式化设计可以尽量的减少数据冗余，更新操作比反范式化更快，但是对于查询需要对多个表进行关联，更难进行索引优化。
反范式化设计可以减少表的关联（顺序IO），可以更好的进行索引优化，但是存在数据冗余及数据维护异常，对数据的修改需要更多的成本（需要修改多个地方）。
因此，我们需要结合反范式化和范式化，设计出高性能数据库结构。