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

编程入门行业动态更新时间:2024-10-11 15:18:54

【网站架构】10年数据库设计浓缩的绝技，<a href=https://www.elefans.com/category/jswz/34/1754630.html style= 实打实的设计步骤与规范"/>

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

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

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

这是因为：

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

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

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

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

分库（由架构师或技术负责人完成）
分表（由开发人员完成）
增加冗余字段、视图（由开发人员完成）

1、分库

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

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

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

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

2、分表

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

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

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

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

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

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

3、增加冗余字段、视图

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

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

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

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