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 pk
  username string unique
  email string
  bio string
}

强调一点：业务逻辑永远不要成为主键，例如这里除了id外所有的属性皆是如此。

也许你不需要一个createdAt键，但一个很中肯的建议是添加它，总有一天你会需要它的，当你需要它的时候可不能后悔。

User {
  id string pk
  username string unique
  email string
  bio string
  createdAt timestamp
}

同样的方法，添加班级、通知，完成后如下图所示：

3. 构建关系

关系分为多种：

• 一对一
• 一对多
• 多对多

这里用户和班级之间存在多对多的关系，构建关系时我们也总遵循从User表开始的原则，正如之前提到的，用户是整个产品的核心。

为了加深对关系的了解，这里举个用户发推文的例子：一个用户能发多个推文，每一条推文只有一个用户作为作者。这是一对多的关系，一个用户对应多个推文，但每一条推文只能对应一个用户。

在这里，假如我希望一个班级对应多条通知，在eraser.io中可以使用这样的语法来表示：

# 一对多
Classes.id < Notifies.classId

这里用到的关系符号是<，同样的还有一对一和多对多，分别用-和<>符号表示数量关系。

观察上面的代码你会发现一个问题：通知实体并没有classId这个键。

这就是我们需要创建的，这里classId是一个外键，表示引用了一个其他表的主键。

我们修改通知Entity的结构：

Notify {
  id string pk
  title string
  content string
  createdAt timestamp
  classId string pk
}

Class.id < Notify.classId

修改后大概是这样：

这里我们再添加一个Media实体：

Media {
  id string pk
  fileUrl string
  type enum
  createdAt 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