目录
3.3 第三范式(确保每列都和主键列直接相关,而不是间接相关)
1 什么是数据库设计
简单来说,数据库设计就是根据业务系统的具体需要,结合我们所选用的DBMS(数据库管理系统),为这个业务系统构造出最优的数据存储模型。并建立好数据库中的表结构及表与表之间的关联关系的过程。从而可以有效的对应用系统中的数据进行存储,并可以高效的对已经存储的数据进行访问。
2 为什么要进行数据库设计
2.1 数据库设计的步骤
2.1.1 需求分析
2.1.2 逻辑设计
2.1.3 物理设计
2.1.4 维护优化
3.数据库设计遵循的三大范式
3.1 第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。
比如该表的省份,城市和详细地址就很好的遵循了三大范式,如果单独用一个字段地址来囊括省份,城市,详细地址的话,以后查询某个省份或者某个城市的用户就会很困难
3.2 第二范式(确保表中的每列都和主键相关)
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。
这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。
这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。
3.3 第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。
比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
4.数据库优化原则
4.1 总体优化原则
(1)不在数据库中做运算,运算务必移至业务层
(2)库命名简洁明确(长度不能超过30个字符)
(3)控制列数量(字段少而精,建议控制在20个以内)
(4)控制列数量(平衡范式与冗余(效率优先,往往牺牲范式))
(5)拒绝3B(大SQL,大事务,大批量)
4.2 字段类优化原则
(1)用好数据类型(用合适的字段类型节约空间)
(2)字符串转换为数字(节约空间,提高查询性能)
(3)避免使用NULL字段(NULL字段很难查询优化,NULL字段的索引需要额外空间,NULL字段的复合索引无效)
(4)少用text类型(尽量使用varchar代替text字段)
4.3 索引类优化原则
(1)合理利用索引(改善查询,减慢更新,索引不是越多越好)
(2)字符字段建前缀索引
(3)不在索引做列运算
(4)innodb主键推荐用自增列,字符串不应该做主键
(5)避免索引失效
a.复合索引尽量全匹配
b.最佳左前缀法则(带头索引不能死,中间索引不能断)
c.不要在索引上加任何操作(计算、函数、自动/手动类型转换),不然会导致索引失效而转向全表扫描
d.msyql存储引擎不能继续使用索引中范围条件(between、<、>、in等)右边的列
e.尽量使用覆盖索引(索引列和查询列一致)
f.索引字段上使用is Null或者is not null判断时,会导致索引失效而转向全表扫描
g.索引字段使用like以通配符开头,会导致索引失效
h.索引字段是字符串,但查询时不加单引号,会导致索引失效而转向全表扫描
i.索引字段使用or时,会导致索引失效而转向全表扫描
4.4 SQL类优化原则
(1)sql语句尽可能简单
(2)简单的事务
(3)避免使用触发器/函数(客户端程序取代)
(4)不要select *
(5)OR改写为in
(6)OR改写为UNION
(7)使用union all代替union
(8)少用连接join(超过3个join,一般移动到业务代码里执行)
(9)分页limit优化(偏移量越大,执行越慢)