# 🏅 Day 36 - 資料庫設計 embedded 嵌入／ references 引用

常見的資料庫設計有：**embedded 嵌入** 及 **references 引用**
實作上也會依不同需求情境來選擇要使用哪種資料庫設計

**embedded 嵌入**：
將相關資訊寫在同一個資料表中

- 需要快速查詢相關資訊時
- 會產生重複的資料

**references 引用**：
將相關資訊寫在不同的資料表中，再將他們建立連結
像是 Day18 練習的 Mongoose populate 語法，就是使用到 references 引用的設計。
因貼文資料會加入 user 欄位把使用者資料加入，不過因使用者的資料在眾多貼文中可能會重複，並且是可能會被修改的，若將資料寫死在貼文資料中，修改上會很麻煩，因此可以將使用者資料另外放一個 Model，在貼文的資料中使用 ref，取得貼文時再使用 populate 關聯使用者資料，確保取得貼文時帶入的是最新的使用者資料

- 需要頻繁更改資料時
- 不同資料需要經常分別查詢時
- 資料不會重複

### 參考資源
- [Embedded Data Versus References](https://www.mongodb.com/docs/manual/data-modeling/concepts/embedding-vs-references/)

題目
---
請依據以下描述的情境選擇比較合適的方案：==**方案 A embedded 嵌入**== 或 ==**方案 B references 引用**==
> [題目來源](https://whimsical.com/3CkqgyD3n3GvsCrdkywruw)


## (B)
1. 製作訂房系統，但希望可以做註冊登入功能，另外儲存使用者資料，訂單資料同時也會需要紀錄使用者的資料
## (A)
2. 以留言板的模式製作一個較陽春的訂房系統，預約一個房型就如同新增一個留言，為了節省開發成本，不會新增其他資料，也不需註冊會員


## (A)
3. 該火車時刻表每天會被查詢近千萬次，班次資料幾乎都是固定的，變更頻率低（很常被讀取，較少被寫入）

## (B)
4. 使用者可以時常新增貼文（無法預測貼文數量），系統也允許修改個人資料。
例如：修改個人大頭貼後，所有該使用者發布的貼文的個人大頭貼都會同步更換
使用者也很常觀看其他人的貼文，貼文中也會顯示個人資訊

## (B)
5. 依設計稿「3-2.全體動態牆-有留言」此頁設計
貼文的數量不可預測，按讚資訊不會顯示出按讚者的資訊，同時使用者資料可能隨時變更