「資料庫，就像韌性生活的倉庫。」
「若沒有清楚的分類與標籤，再多的物資也會在混亂中失效。」

為什麼資料庫是關鍵？

在前端與後端的基礎搭建完成後，專案最需要的一塊拼圖就是「資料庫」。
對於 防災物資智慧推薦平台 而言，資料庫不只是存放資訊的地方，而是整個專案的 核心骨架 ：

1.標準化： 官方清單（國防部全動署、全民安全指引、東京防災）都給了參考，但需要轉換為統一結構，才能計算與推薦。
2.擴充性： 未來可能加入「特殊需求族群」（嬰幼兒、長者、寵物）的額外物資，因此資料結構必須可擴充。
3.即時性： 若要串接電商 API（momo、PChome），資料庫必須能同時處理靜態清單與動態價格／存貨資訊。

為什麼選 MongoDB Atlas？

資料庫的選擇，不只是「技術喜好」，而是與 side project 的開發效率與靈活性 高度相關。

• 文件導向（Document-based）： MongoDB使用JSON-like文件，結構自然貼近「物資清單」的邏輯。
  • 例：{ "item": "飲用水" , "category": ** "食物"** , "unit": "瓶" , "amount": 3 }
• 雲端管理（Atlas）： 免維運，快速上手，支援免費層級，非常適合個人專案。
• 彈性 Schema： 面對「不同家庭人數／需求」時，欄位可動態增減，不必一開始就定死。
• 與 Node.js 生態相容： Mongoose、官方driver都能順暢搭配Express使用。

資料表（Collection）設計構想

專案的目標不是「單純存放清單」，而是要讓清單可以被** 篩選、計算、個人化推薦** 。因此需要有層次的結構。

1.items：物資主表
* item_id：物資代碼
* name：品名（飲用水、罐頭、口罩）
* category：分類（食物、醫藥、照明、通訊…）
* unit：單位（瓶、包、個）
* shelf_life：保存期限（月數）
* tags：關鍵字（嬰幼兒專用、防疫必備…）

2.scenarios：情境表
* scenario_id：情境代碼
* name：災害類型（地震、颱風、停電…）
* required_items：建議物資清單（對應 items 的 ID 列表）

3.users：使用者偏好
* user_id
* household_size：家庭人數
* has_pets：是否有寵物
* age_group：世代（嬰幼兒、成人、長者）
* custom_items：使用者額外新增的物資

4.sources：資料來源
* source_id
* organization：提供者（國防部、東京都…）
* reference_url
* last_updated

實際應用案例

以「四口家庭、含一名嬰幼兒」為例：
1.使用者輸入家庭人數、年齡層 → 系統查詢 users → 建立 profile。
2.系統比對 scenarios（地震＋停電） → 抓取 required_items。
3.從 items 撈出「一般必備物資」＋標記 tags=嬰幼兒 的額外需求。
4.最後整合 sources → 標註清單出處，提升可信度。

這樣，不同家庭、不同情境，就能動態產生個人化的防災物資清單。

挑戰與思考

• 清單歧異： 不同來源的數量建議不同，如何融合？ → 可用「基準範圍」＋「建議值」呈現。
• 電商串接： 動態比價與庫存更新，需避免資料過舊導致誤導。
• 可持續性： 如何讓清單不只是「一次性的查詢」，而是能透過提醒功能，引導使用者定期檢查？

結語

在這個專案中，MongoDB Atlas 不只是技術選擇，更是 把散落的防災資訊轉化為結構化知識 的工具。
而這樣的知識，一旦被整理成可以查詢、延伸、擴充的資料庫，就能真正成為**「韌性生活指南」**的原理基礎。

下一步（Day 15），我們將進一步探討——如何讓 AI 模組讀懂這些結構化資料，並給出個人化的推薦。