小程序·雲開發數據庫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關係的三種設計模式，它們各有各的優勢，在使用的時候須要結合實際的應用場景來選擇合適的設計模式。