【网站架构】10年数据库设计浓缩的绝技，实打实的设计步骤与规范

本期，我们来聊一下数据库设计，在开始讨论数据库设计之前， 我们先要明确一个观点，数据库是大多数业务系统的核心， 数据库设计也是十分重要的设计。

但是，这并不代表数据库设计是一件很困难的事情 ，对于我们提供技术支持的团队 ，我们一直坚持让后端开发人员直接设计数据库（无论此开发人员的经验多少） ，而不是让经验丰富的开发人员包揽数据库设计的工作（经验丰富的开发人员做好评审即可）。

这是因为 ：

1、数据库设计没有必要一次性完整地设计出来 在开发过程当中，难免需要对数据库进行调整 ，只要数据库的骨架没有问题（经验丰富的开发人员做好评审即可） ，诸如增删字段、添加中间表、添加视图等都不会造成多大的影响。

2、数据库设计是后端部分需求转化的过程（一般的业务系统），好比原型设计是前端部分的需求转化过程一样 ，通过数据库分库分表 就能大概地描画出后端功能的结构（一般的业务系统）， 如果后端开发人员跳过了数据库设计（使用别人的数据库设计） ，就必然会出现分不清功能结构的状况 ，只能根据页面原型猜测需要哪些接口 ，这种看到一个功能开发一个接口的工作模式 ，先不论代码写得怎么样 ，大多数情况下会出现开发进度不可控、开发多余接口、漏写接口等问题。

所以，数据库设计是每个后端开发人员都必需掌握的技能 ，而数据库设计其实也不难 我们不要想着一次性完整地把数据库设计出来 ，我们只要把骨架设计出来即可（设计评审和后续开发时再调整） 。

我们推荐的数据库设计步骤分为以下3个步骤 ：

1. 分库（由架构师或技术负责人完成）

2. 分表（由开发人员完成）

3. 增加冗余字段、视图（由开发人员完成）

1、分库

经常看见一些系统只有一个数据库 ，这个库里有几百上千张表， 相信无论E-R图画得再详细，还是说明写得有多好 都不会有人能搞清楚它们的关系。 这无疑是系统越做越烂的主要原因之一 ，也是微服务无法发挥它本该有的效果的原因之一（用的是同一个数据库，后端服务扩展更多的服务器也没用）。

所以分库的目的：一是为了降低单个数据库中数据表的复杂度（更容易理解）；二是为了在后续扩展服务器时，更有针对性地扩展（只扩展请求压力比较大的部分）。

分库的原则很简单 ，一般而言，每个子系统对应一个数据库即可 。如用户系统、博客系统、商城系统、流程系统都有自己独立的数据库， 而系统划分更多的是根据业务架构而定 ，业务架构设计可参考我们之前关于业务架构的视频 ，另外，对于一些数据紧密关联的子系统，如优惠券与资金系统， 则最好合并成一个系统。

 当然，数据库独立了之后会有一些问题 ，对于大多数场景而言，通过前端调用多个接口整合就可以了 ，但诸如一些需要数据强一致的场景， 则会涉及到数据库分布式库事务 ，关于数据库分布式事务会在下一期内容详细介绍。

2、分表

分表更多的是按照当前模块的业务功能而定的 ，以一个博客系统为例 主要的业务逻辑为，用户写博客，管理员审核后，其他用户即可查看，且可以在博客下面评论， 即可以创建对应的四张表 。但是，由于审核其实就是一个状态，用一个字段记录即可 ，所以只需要两张表 ，一是博客表、二是评论表。

定义好主要的几张表后 需要纵观此系统的所有功能点， 看是否需要增加额外的表 ，如发现博客系统中有收藏功能， 则考虑增加收藏表。

 分表完成后，还需要分析表与表之间是否存在多对多的关系 。如博客存在标签分类，那么博客与标签就是多对多的关系 。

对于这种多对多的关系有两种解决方案：

• 建立中间表记录；
• 在其中一张表中用一个字段或多个字段记录此关系。

 分表完成后， 一个模块的功能结构就大概勾勒出来了 ，在开发时，也明显知道哪些功能是主要的、哪些功能是次要的 以至于开发计划更加明确、前后端连调也能分阶段完成 。分表后，单个数据库的结构是基本清晰了 ，但是对于一些特殊功能 ，如在个人中心的评论列表里 ，除了要显示评论内容，还需要显示该博客的名称。

3、增加冗余字段、视图

此时就要考虑添加冗余字段了， 即在评论表中也记录博客的名称（在博客表中已经被记录） 当然，冗余字段的更新是麻烦的 ，所以冗余字段适合一些更新频率很低或者允许不更新的字段。

当然，除了冗余字段，也可以通过SQL语句实现夸表查询 ，对于这种夸表查询，我们更推荐使用视图 ，视图说白了就是数据库中保存好的一条SQL查询语句 ，视图能简化后端SQL语句的复杂度， 也能通过查找哪些接口使用了视图从而知道它做了跨表查询（方便后续性能调优）。

例如，需要按热度排列出热门博客 ，而热门是根据收藏数、点赞数、评论数乘以各自的权重决定的 。那么就可以做一个视图建立一个博客热度的虚拟表， 用一条简单的SQL语句就可以查询热度前3的博客（实际项目需要添加Redis缓存）， 也可以用一条简单SQL语句的就可以查询出某个分类下的热度前3的博客（实际项目需要添加Redis缓存）。

视图除了以上的好处 ，还有一个好处：跨库查询（虽然直接使用SQL语句也能做到，但视图能更规整一些）， 如果多个数据库是在同一个MySQL服务中的话， 则视图是可以夸数据库查询的（普通SQL语句也可以）， 如果数据库在不同的MySQL服务中（MySQL5.7以后）， 也可以通过数据同步把需要查询的数据同步过来 ，再通过视图夸库查询 。当然，一般这种方式大型网站是不常用的， 因为如果同步的数据库的数据量过大或更新频率较高的话 ，则往往得不偿失 。

命名规范

我们推荐的数据库命名规范是这样的，数据库的名称与系统名相同即可，表名用t_开头，视图以v_开头 表中的字段， 如果是表中独有的，用表名_开头 ，如果是外键，则使用其原本的名称 ，视图不改变字段的名称 。这样，即使没有E-R图 ，也能通过字段名判断表与表的关系。这样做虽然看起来简单，但能预防很多不必要的bug。

总结

数据库设计当然也包括索引、具体字段、字段类型及长度等 。不过这些问题其实在实际开发过程中添加即可 ，在一开始过于细致地考虑这些问题反而在浪费时间（甲方或是业务部门要求除外）。

以上就是我们推荐的数据库设计过程 当然，数据库设计从来没有绝对的最优解 ，数据库设计是否相对合理取决于业务功能的了解程度以及项目经验。

不过不用担心做不好， 因为不做就永远都做不好， 只要多做几次和多被有经验的人评审几次后， 相信你的数据库设计将会越来越成熟。