后端开发之数据库设计（二）物理设计

前面说到数据库的逻辑设计，始终是计划阶段，现在总是要将这些设计赋予实现，就是我现在要说的数据库物理的实现了，经过现在要说的，我们就能得到一个用于项目的数据库了。

物理设计

在数据库的物理设计中，最主要的自然是决定确定数据存储结构，在数据的存储时间和空间利用率中权衡，选择一个折中的方案，这个折中方案的选择必然是需要大量的经验作为选择的支持，但仍然有套路式的方案，理解并记住这些方案方便我们很快决定数据的存储结构等。按照物理设计的基本步骤，我们需要先选择合适的 DBMS 系统，因为不同的 DBMS 系统的数据类型稍微会有点区别，所以现决定 DBMS 系统是必须的。

选择 DBMS 系统

常见DBMS系统.png

以上是比较常见的 DBMS 系统，我们可以根据以下特点对 DBMS 系统进行选择。

1. 选择选择商业数据库还是开源数据库，商业数据库需要考虑版权。
2. 从性能方向考虑，oracle 性能比较高的，项目需要大的事务操作时可考虑，其他情况可选择其他数据库。
3. 从我们使用的操作系统上，像是 SQLServer 是只支持在 window 下使用，其他数据库是可以运行在 linux、windows 下的。
4. 从开发语言来看，如果选择的是 .net 语言的话，选择 SQLServer 会比较好一点，与 .net 配合比较好。
5. 从应用场景来看，mysql 和 pgsql 这类开源数据库比较适合互联网项目，而 oracle 和 sqlserver 更常见于企业级项目。

由于现在接触比较多的还是互联网的项目，所以以下的例子使用 mysql 做介绍。

选择 MySQL 存储引擎

这里就贴一个图说明下各个存储引擎的特点，详细介绍可以看我分享的数据库学习视频。

mysql存储引擎.png
大部分情况下，我们都是选择 Innodb 这个存储引擎的。

定义数据库、表、字段的命名规范

为了在整个开发团队中明确数据库的定义，所以我们是需要定义命名规范的，有了命名规范，开发团队就能很快知道数据库是干嘛，数据库中的表的内容，每个字段表示什么含义，这和我们写代码用有意义的命名的目的是类似的。以下是表和字段的命名规则。

1. 可读性原则：用有意义的单词作为字段名，可以用大小写区分开来，但由于在设置数据库的时候可以设置对大小写的敏感，所以用下划线区分开来比较合适。
2. 表意性原则：通过表的名称就能够知道表中存储的数据内容。
3. 长名原则：尽量不使用缩写命名，因为有歧义。

选择合适的字段类型

选择合适的字段类型是在物理设计中最主要的一个工作，但这个选择其实没有类似于设计范式那样这么规范的规定，同一个字段可以选择不同的字段类型去存储，这里提供一个原则。

当一个列可以选择多种数据类型时，优先选择数字类型，其次是日期或二进制类型，最后字符型，对于同级别的数据类型来看，优先选择占用空间小的数据类型。

选择合适的字段类型面试的时候经常被问道，下面举一些常问的例子：

• varchar 和 char 类型的选择
  1. 如果列中要存储的数据长度差不多是一致的，则应该考虑用 char；否则应该考虑用 varchar。
  2. 如果列中的最大数据长度小于 50Byte ，则一般也考虑用 char（当然，如果这个列很少用，则基于节省空间和减少 I/O 的考虑，还是可以选择用 varchar）
  3. 一般不宜定义大于 50Byte 的 char 类型列。
• 日期类型存储
  datetime 类型：存储时原样输入输出，和时区无关。占8字节存储空间。
  timestamp 类型：把客户端插入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回。占4字节空间。
  date 类型：只有日期，例如生日，可以直接利用时间函数进行时间的计算。占3字节空间。

  注意不要使用字符串类型来存储日期时间数据，使用 int 存储日期时间不如使用 timestamp 类型

• decimal 与 float 类型选择
  1. decimal 用于存储精确数据，而 float 只能用于存储非精确数据，故精确数据只能选择用 decimal 类型
  2. 由于 float 的存储空间开销一般比 decimal 小（精确到7位小数只需要4个字节，而精确到15位小数只需要8字节）故非精确数据优先选择 float 类型

其他注意事项

• 选择主键：考虑主键是否要顺序增长，所占空间要尽可能小。
• 避免使用外键约束：会降低数据导入的效率，增加维护成本。
• 避免使用触发器：会降低数据导入的效率，可能会出现意想不到的数据异常。
• 不需要预留字段

反范式设计

前面我们在逻辑设计的时候说到了设计范式，我们遵循设计范式，设计出完全没有冗余数据的数据表，而反范式化就是通过增加冗余数据，减少表的关联，即是我们说的空间换时间。
对于反范式的设计是没有什么原则或者规范的，可以选择对关联表之后只为了查多一个字段的数据进行反范式设计，这个是比较依靠经验的。

这就是数据库物理设计的内容，物理设计对数据库的查询效率乃至系统的性能是十分重要的，当我们的系统使用人数或者并发达到一定的数量级就不能简单的按照设计范式去做数据库设计，物理设计本身就是时间、空间的权衡，是没有绝对的设计规则的，大家初期可以按照我上面提出的方法做。

现在关注我的公众号，后台回复【数据库】可以获取《打造扛得住的MySQL数据库架构》视频学习资料一份，欢迎大家关注！

---

欢迎关注微信公众号 乱点技能树的小猿
日常发布初出茅庐程序员一些胡言乱语以及编程资源，漫漫编程路，希望我们一起进步！

欢迎关注.jpg