第一步 定義要描述的資料集
當我們決定將資料儲存下來的時候,我們首先要回答的一個問題就是:“我打算儲存什麼樣的資料?這些資料之間有什麼關係?實體之間有什麼關係?實體的屬性之間有什麼關係”。
為了說明問題,我們這兒舉例的場景是要描述 庫存清單的資料庫,庫存清單資料 包括 物料名稱、數量、規格大小、狀態、標籤說明、等級。
如下list是我們希望關於庫存清單的部分格式資料
name | quantity | size | status | tags | rating |
---|---|---|---|---|---|
journal | 25 | 14×21,cm | A | brown, lined | 9 |
notebook | 50 | 8.5×11,in | A | college-ruled,perforated | 8 |
paper | 100 | 8.5×11,in | D | watercolor | 10 |
planner | 75 | 22.85×30,cm | D | 2019 | 10 |
postcard | 45 | 10x,cm | D | double-sided,white | 2 |
(備註: cm 為長度單位,釐米;in 也是長度單位:1in=25.4mm==2.54cm)
第二步 JSON 化 思維
上面表中的size 和 tags 欄位 都儲存了多個值,例如Size 既有大小 的數字描述還有它們單位的描述,tags 這種標籤的說明更是難以統一,可能此物料只有一個屬性說明,而其他物料可能有多個屬性的說明。這種欄位如果在關係型資料庫中儲存,假設儲存在一個欄位中,那麼查詢起來比較費時,模式化也比較困難。如果拆開放到不同的表中,完整性就不是很好,表的設計也是難以清晰,表Join查詢也會有效能下降。
在MongoDB 資料中,資料都是以文件的形式儲存的。這些文件都是以JSON(JavaScript Object Notation)格式設計存在的【物理盤上實際是以BSON格式儲存的】。JSON文件支援內嵌欄位。因此,我們可以將關聯性強的資料或同一個List中的資料儲存在同一個文件中,此時,不再需要儲存在SQL資料庫中多個表中【如果在SQL資料庫,需要多個表,來描述關聯】。
JSON 格式就是將資料存為 鍵/值對 。在JOSN文件中,鍵和值 之間用 冒號(:)隔開;一個個鍵/值之間用逗號(,)隔開,同一個文件中的一組鍵/值包含在一個花括號({})中。
例如,下面List中的 name
和 quantity
欄位資料 JSON化,
name | quantity | size | status | tags | rating |
---|---|---|---|---|---|
notebook | 50 | 8.5×11,in | A | college-ruled,perforated | 8 |
將這兩個欄位JOSN化,就是下面這個形式:
{"name": "notebook", "qty": 50}
第三步 針對多值欄位,選擇合適的資料模型
針對多值的欄位,我們可以從內嵌模型、陣列 List 模型兩種資料模型中選擇一種。
例如上面 庫存清單資料的那個例子,我們可以將Size,設計成內嵌模型,這個Size 可以有三個屬性:高、寬、計量單位。
{ "h": 11, "w": 8.5, "uom": "in" }
一些商品原料,可能又多個等級得分,我們可以將這些等級得分儲存在一個陣列list中,例如上面例子中的ratings欄位。
[ { "score": 8 }, { "score": 9 } ]
上面例子中的tags 也可以存放在陣列list中
[ "college-ruled", "perforated" ]
那麼其中的關於notebook的記錄資料 如下
notebook | 50 | 8.5×11,in | A | college-ruled,perforated | 8,9 |
而將其 JOSN 化後,要存的文件樣式如下:
{
"name": "notebook",
"qty": 50,
"rating": [ { "score": 8 }, { "score": 9 } ],
"size": { "height": 11, "width": 8.5, "unit": "in" },
"status": "A",
"tags": [ "college-ruled", "perforated"]
}
以上過程就是資料記錄的JSON過程、文件化過程。
注: 以上內容作者翻譯自 MongoDB 官網,網址為 https://docs.mongodb.com/guides/server/introduction。
因作者非專業翻譯人員,難免有錯誤或不準確的地方,請見諒。