小程序·云开发数据库1对N关系的三种设计模式

了解太小程序的人，确定都知道小程序的云开发模式，不知道的如今应该知道了。 在用云开发来开发产品的时候，若是只是一些简单的应用，须要处理的数据不是不少，在云数据库中建几个collection就能应付的那种，那么小程序的云开发文档已经足够了；可是若是想用云开发来开发一个复杂一点的产品，不对数据库进行一番设计是不行的。

今天要给你们介绍的是如何在云数据库当中设计1对多的关系，云数据库是一个非关系型数据库，对于这种1对多关系在项目中也是很是的常见，好比用户在外卖app里填的地址可能会有多个，这里的用户就是1，填的地址就是多；再好比咱们在大学里选修课程，学生就是1，而全部的课程就是多；还有就是你如今看的这篇文章和评论的关系，一篇文章确定会对应多条评论。这些都是一对多的关系，提及来很简单，但咱们如何将这种关系在数据库当中展现或者设计出来呢？别急，慢慢来。

一对多的关系主要分为三种场景，其实我上面举的三个例子分别就是对应的三种不一样的场景。有的人可能看不出三个例子有什么不一样。别急，慢慢品。

对于例子一，“1”就是用户，“N”表示接收外卖的地址。用户的地址个数不会太多，通常就是公司一个地址，住的小区一个地址，实习生可能还有个学校宿舍的地址。对于这种“N”的数量不是不少的状况，咱们能够建立一个User集合，而后将用户的全部地址放到用户的子集中，就像下面这样：

User集合

{
    uid: 1,
    addressList: [{...}, {...}, {...}],
    ...
}
{
    uid: 2,
    addressList: [{...}, {...}, {...}],
    ...
}
...
复制代码

这是很是简单，很是方便的一种设计方式，查询的时候只须要遍历User集合一次就能拿到“1”的全部数据和“N”的全部数据了。

如今咱们来看下第二个例子 - 学生选课，粗略一看，这和场景一没什么区别嘛，一个学生最多也就选择十几门课，彻底能够将学生和课程都放在一个Student集合里，就像下面这样：

Student集合
...
{
    studentId: 1,
    courseList: [{courseId: 1, ...}, {courseId: 2, ...}, {courseId: 3, ...}, ...],
    ...
}
{
    studentId: 2,
    courseList: [{courseId: 4, ...}, {courseId: 5, ...}, {courseId: 6, ...}, ...],
    ...
}
...
复制代码

但事情并无这么简单，假设如今课程1的老师请假了，须要由另外一位老师来代课，那么课程1里面老师相关的信息就须要同步地改为代课老师的信息，在上述设计模式下就须要遍历全部学生的课程数组，逐一地找到目标课程进行修改，更改的效率比较低。有没有更高效方式呢？答案是确定的。第二种设计模式就是将学生和课程放在两个集合里，学生的课程列表里存放其所选课程的id，以下所示：

Student 集合
...
{
    studentId: 1,
    courseIdList: [1, 2, 3, ...],
    ...
}
{
    studentId: 2,
    courseIdList: [4, 5, 6, ...],
    ...
}
...
-------------------------------分割线---------------------------
Course 集合
...
{
    courseId: 1,
    courseName: "课程1",
    teacherName: "老师1",
    ...
}
{
    courseId: 2,
    courseName: "课程2",
    teacherName: "老师2",
    ...
}
...
复制代码

如今当咱们修改课程信息的时候只须要遍历一遍Course集合就能够了，这样设计还有其余的好处：学生在选课的时候须要查看全部的课程信息，咱们只须要将Course集合里的数据所有返回给前端就能够了，若是采用第一种设计模式，咱们还须要对数据进行很是复杂的过滤操做，处理逻辑很是地不天然，也并不高效。相较而言，第二种模式更加的高效和天然。但第二种设计模式也有缺点，缺点就是当咱们查询一位学生所选的课程的时候咱们须要遍历两个集合，首先须要遍历Student集合找到目标学生包含的课程id，而后遍历Course集合筛选出课程。

最后咱们来看下第三种场景 - 文章评论，在这种场景里“1”表明文章，“N”表明评论。一篇文章的评论数是不受限制的，能够有不少。好比流量明星的一篇微博的评论数，破千上万那是基本操做。在这种“N”的数量级特别大的状况下，第一种设计模式显然不能被采用。目光投向第二种设计模式，成千上万的评论id被塞在一个数组里，看上去很不优雅，并且数组的长度是有限制的，不能存放太多。这时，一种适合此情此景的设计模式呼之欲出：

Article 集合
...
{
    article: "文章1",
    articleId: 1,
    ...
}
{
    article: "文章2",
    articleId: 2,
    ...
}
...
----------------------------------分割线-----------------------
Comment 集合
...
{
    comment: '评论1',
    commentId: 1,
    articleId: 1,
    ...
}
{
    comment: '评论2',
    commentId: 2,
    articleId: 1,
    ...
}
{
    comment: '评论3',
    commentId: 3,
    articleId: 2,
    ...
}
复制代码

上面的demo就是模式三的基本结构，虽然模式二和模式三都是将“1”和“N”分在两个集合里，可是却有明显的不一样。模式二是在“1”中保存了“N”的id信息，而模式三是在“N”中保存了“1”的id信息，能够看到在上面的Comment集合里，每条评论都有一个articleId字段，表示该条评论属于这篇文章（articleId={articleId}的这篇文章）。属于同一篇文章的评论，它们的articleId都是相同的。当全部的评论都放在一个集合里的时候，咱们就能够经过articleId来进行高效的筛选了。

好了以上就是数据库中1对N关系的三种设计模式，它们各有各的优势，在使用的时候须要结合实际的应用场景来选择合适的设计模式。