一、逻辑设计
1.范式设计
（1）数据范式设计一
- 数据库表中的所有字段都只具有单一属性
- 单一属性的列是由基本的数据类型所构成
- 表是简单的二维表
如：
错误的范式
字段name-age不是单一属性
| id | name-age |
|---|---|
| 1 | xiaoming-18 |
正确的范式
| id | name | age |
|---|---|---|
| 1 | xiaoming | 18 |
（2）数据范式设计二
- 表中只存在一个业务逐渐，而不能存在非主键列只对部分主键的依赖关系。
错误范式：产品与订单的ID没有直接的关联关系
产品表
| id | name |
|---|---|
| 1 | 游戏机 |
| 2 | 手机 |
订单表
| id | address | prd_id |
|---|---|---|
| 1 | 北京 | 1 |
| 2 | 上海 | 1 |
正确范式：
产品表
| id | name |
|---|---|
| 1 | 游戏机 |
| 2 | 手机 |
订单表
| id | address |
|---|---|
| 1 | 北京 |
| 2 | 上海 |
订单中间表
| id | order_id | prd_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
（3）数据范式设计三
- 非主键列不能依赖其他表的非主键列。
错误范式：
订单与客户姓名关联
订单与客户编号关联
客户姓名和客户编号关联。
不应该将客户编号和客户姓名存放在订单中，如果修改用户表中的姓名和编号修改
则需要对订单中的客户编号和姓名进行修改。
| id | address | 客户姓名 | 客户编号 |
|---|---|---|---|
| 1 | 北京 | 小明 | bj123 |
| 2 | 上海 | 如花 | sh123 |
2.反范式设计
- 反范化设计为了提高范式化导致性能和读取的效率问题，从而适当的对数据范式设计进行违反。
- 通过少量的冗余数据，提高读取效率和性能上的问题，这种方式就是空间换时间。
3.范式化与反范式化的优缺点
范式设计
优点：
- 尽可能减少数据的冗余
- 范式化比反范式化的更新操作更快
- 范式化的表比反范式化的表更小。
缺点： - 对于表的查询需要对多个表进行关联
- 更难进行索引优化
反范式设计
优点：
- 减少表的关联
- 可以更好的进行索引的优化
缺点： - 存在数据冗余和冗余数据的维护
- 多数据的修改需更多的成本去处理
二、物理设计
（1）物理设计的过程
- 定义数据、表和字段的命名规范
- 选择合适的存储引擎
- 字段选择适合的数据类型
- 根据业务设计合理表和表之间的关联关系
- 建立数据库结构
（2）命名规范
- 数据库、 表、字段必须遵循可读性原则。
- 数据库、 表、字段必须遵循表意性原则，表的名字能够描述表的功能、模块等。
- 数据库、 表、字段必须遵循长名原则，尽可能的少用缩写的名字。
- 数据库、 表、字段应使用英文或者拼音的专有名词。不要使用拼音。
（3）存储引擎的选择
| 对比项 | MyISAM | InnoDB |
|---|---|---|
| 主外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 行表锁 | 表锁，不适合高并发操作 | 行锁，适合高并发操作 |
| 缓存 | 缓存索引，不缓存查询的数据 | 不仅缓存索引，还会缓存查询数据，对内存要求较高，而且内存的大小会对性能造成影响 |
| 表空间 | 小，因为MyISAM会压缩 | 大 |
| 关注点 | 性能 | 事务 |
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
仅从锁的角度来说：
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用。
行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理系统。
（4）数据类型的选择
- 优先考虑使用数字类型
- 其次日期和时间类型
- 最后字符串类型
- 对于相同级别的数据类型，优先考虑使用占用空间较少的数据类型。
- 对精度有要求的时候，选择精度高的数据类型。 int<float<double<decimal.
datetime 与timestamp 都是日期类型，datetime与时区无关，而timestamp与时区有关。timestamp本质是使用int进行存储。所以效率会比datetime高。但是要考虑时区的问题。
