逻辑设计
范式设计
第一范式:列不可再分(1NF)
- 数据库中的所有字段都只具有单一属性
- 单一属性列是有基本数据类型构成
- 设计出来的表都是简单的二维表
- 例如:用户数据中的地址,不能使用北京市西城区xxx街道xxx小区存为一个字段,应该将可拆分部分拆分,省,市,区县,详细地址独立字段存储
第二范式:一行数据只做一件事(2NF)
- 一行数据值做一件事
- 例如:一个人在商城下多个订单,联系人为重复,这样就要拆分出来
第三范式:数据库不存在传递依赖关系(3NF)
- 数据中不存在通过非主键关联的字段
- 例如:订单中的收货地址,不能通过手机号关联地址中的数据,只能通过地址中的id关联
反范式
范式中的问题:范式会产生大量关联表,数据库通过join查询,非常影响性能。
- 反范式设计是针对范式化而言
- 所谓反范式化就是为了性能和读取效率考虑而适当对数据库设计范式要求进行违反
- 允许存在少量的冗余,换句话说,反范式就是使用空间换取时间,通过冗余字段,减少join查询
物理设计
命名规范
- 数据库,表,字段要遵守可读性规范。如使用custAddess,而不是custaddress
- 数据库,表,字段要遵守表意性原则。名称应该能描述对应库,表,字段所表述的对象
- 数据库,表,字段要遵守长名原则。尽可能少用或不用缩写
存储引擎选择
对比项 | MyISAM | InnoDB |
---|---|---|
主外键 | 不支持 | 支持 |
事务 | 不支持 | 支持 |
行级锁 | 不支持 | 支持 |
缓存 | 只缓存索引,不缓存真实数据 | 缓存索引和真实数据,对内存要求比较高,内存大小对性能有很大影响 |
表空间 | 小 | 大 |
关注点 | 性能 | 事务 |
默认 | 5.5版本之前 | 5.5版本之后 |
数据类型选择
- 优先选择数字类型
- 其次是日期、时间类型
- 最后是字符串类型
- 相同级别的数据类型,应该优先选择占用空间小的类型