如何在MongoDB設計儲存你的資料（JSON化）？
第一步 定義要描述的資料集
當我們決定將資料儲存下來的時候，我們首先要回答的一個問題就是：“我打算儲存什麼樣的資料？這些資料之間有什麼關係？實體之間有什麼關係？實體的屬性之間有什麼關係”。
為了說明問題，我們這兒舉例的場景是要描述 庫存清單的資料庫，庫存清單資料 包括 物料名稱、數量、規格大小、狀態、標籤說明、等級。
如下list是我們希望關於庫存清單的部分格式資料
| name | quantity | size | status | tags | rating |
|---|---|---|---|---|---|
| journal | 25 | 14x21,cm | A | brown, lined | 9 |
| notebook | 50 | 8.5x11,in | A | college-ruled,perforated | 8 |
| paper | 100 | 8.5x11,in | D | watercolor | 10 |
| planner | 75 | 22.85x30,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.5x11,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.5x11,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。 因作者非專業翻譯人員，難免有錯誤或不準確的地方，請見諒。