关系型数据库设计指南
1. 前言
在自己独立开发一个项目的过程中，我发现了一些以往写小 Demo 从来没有遇到过的问题。
最近在独立制作一个全栈的通知管理平台。一开始我没有考虑太多，直接根据头脑中零星的想法就开撸后端数据库 model 和 API，用的是学了半成品的 MongoDb。
结果就是写到后面在遇到复杂的数据库依赖关系时，我感到崩溃。这才想起指导老师给我发了一篇计算机的论文，我便开始虚心研究。
做一个项目要经过这些过程：
- 系统分析
- 可行性分析
- 用户需求分析
- 整体功能模块分析
- 技术分析
- 系统流程分析
- 系统设计
- 系统功能模块设计
- 系统结构设计
- 数据库概念设计
- 数据库设计
- 数据库表设计
- 系统实现
- 功能模块的实现
- API 接口功能的实现
- 系统测试
- 黑盒和白盒测试
- 测试环境与条件
- 功能测试
敲代码的时候思维很局限，总觉得完成了某一个单个功能就算成功。真到让我独立设计一个项目，我还真就难住了。这里就来讲讲我第一个遇到的问题，数据库怎么设计？
本文用到的工具：
eraser.io
2. 构建实体
打开一额eraser.io文件，在左侧写入所有的实体Entity，例如：
- 用户
- 班级
- 通知
然后在canvas中添加一个Diagram as Code > Entity Relationship也就是E-R图。
✨ 一个最佳实践：总是从用户表
User-Table开始着手你的 E-R 图设计。
这是因为，一切都是为了用户用户就是上帝。
从用户表开始，并从用户的注册开始。
我们的用户表可以是这样：
User {id string pkusername string uniqueemail stringbio string
}
强调一点：业务逻辑永远不要成为主键，例如这里除了
id外所有的属性皆是如此。
也许你不需要一个createdAt键，但一个很中肯的建议是添加它，总有一天你会需要它的，当你需要它的时候可不能后悔。
User {id string pkusername string uniqueemail stringbio stringcreatedAt timestamp
}
同样的方法，添加班级、通知，完成后如下图所示：
3. 构建关系
关系分为多种：
- 一对一
- 一对多
- 多对多
这里用户和班级之间存在多对多的关系，构建关系时我们也总遵循从User表开始的原则，正如之前提到的，用户是整个产品的核心。
为了加深对关系的了解，这里举个用户发推文的例子：一个用户能发多个推文，每一条推文只有一个用户作为作者。这是一对多的关系，一个用户对应多个推文，但每一条推文只能对应一个用户。
在这里，假如我希望一个班级对应多条通知，在eraser.io中可以使用这样的语法来表示：
# 一对多
Classes.id < Notifies.classId
这里用到的关系符号是<，同样的还有一对一和多对多，分别用-和<>符号表示数量关系。
观察上面的代码你会发现一个问题：通知实体并没有classId这个键。
这就是我们需要创建的，这里classId是一个外键，表示引用了一个其他表的主键。
我们修改通知Entity的结构：
Notify {id string pktitle stringcontent stringcreatedAt timestampclassId string pk
}Class.id < Notify.classId
修改后大概是这样：
这里我们再添加一个Media实体：
Media {id string pkfileUrl stringtype enumcreatedAt timestamp
}
很显然，一个班级对应多条通知，一条通知可能对应了多个媒体，所以媒体也需要一个类似的外键来唯一的引用一个它所对应的通知。
你有没有想过为什么反过来不行，为什么不是通知的外键引用到媒体呢？
很显然，通知对应多个媒体，一条外键是不够的，而媒体只对应一个通知，一个外键就刚好。
添加完成后我们再来加上颜色和图标就是这个效果：
关键其实还有语义化的功能，在看到这个外键后就知道通知与某个班级有关，媒体与某条通知相关。
在这种情况下外键是很有意义的。
如果我们的用户能够在每一条通知下进行评论，就需要一个Comments实体。很明显他用外键和唯一的用户关联表示该用户的评论。
在这里，用户和评论是一对多的关系，通知和评论也是一对多的关系，所以你能看到在评论的身上有两条外键分别拉到了用户和通知身上。
根据同样的一对多的原理，我们来制造一个like，也就是用户对评论的点赞：
4. 多对多
根据上面的例子我们不难发现，要处理一对一、一对多的关系都能直接使用外键来处理。
但是多对多呢？
用户的好友是一个多对多的关系，用户可以有多个好友，很多人也可以加这个用户作为好友。
我们的班级和用户之间也是这样的关系，班级可以有很多成员而成员也能加入很多班级。
对于多对多的关系我们一般新建一个表，例如，用户好友的关系。
这里比较令人困惑，要仔细看看。
这张表实际上就是单独跟踪了谁关注了谁，有两个字段：关注follow，粉丝follower。
如果要查询用户的粉丝可以用select * from Friends where follow = user_id就能查询到用户的所有粉丝。
如果要查询用户的关注列表就是：select * from Friends where follower = user_id。
5. 总结
关于数据库的设计关键是将所有实体抽象出来，并理清楚实体之间的关系。
本次实验🧪的链接：https://app.eraser.io/workspace/1GT4Nb82OR4LTYIuOmkT