MongoDB Schema 設計系列 (三)：Design Pattern 導入前言與副作用
在前一篇中，我們介紹了 Entity 的關係和關聯方式，這篇是 pattern 的前言，內容是介紹 pattern 帶來的問題，pattern 就像一把雙面刃，沒有仔細了解就使用，最終很容易遇到一些副作用。
和 coding 一樣，data modeling 也有由前人的經驗形成的 design pattern。
pattern 是用來「解決問題」，問題可以是效能問題（執行時間）或是資源問題（記憶體），但並不是每個問題都值得用 pattern 來解決，會這麼說的原因是因為 pattern 不是萬靈丹，它是犧牲某些東西來解決問題，就像演算法中有時是用空間換取時間，又或是時間換取空間。
在設計 schema 時請秉持著 simplicity over complexity 原則，沒遇到問題硬要套 pattern 就是過度設計了。
Pattern 帶來的問題與副作用
1. Duplication (資料重複)
有些 pattern 為了要解決效能問題，會將同一個資料散佈在不同的 collection，目的是為了減少跨 collection 存取資料的次數（回想一下之前提到的 design principle ⇒ 常一起出現的資料盡量放一起）。
但這會造成空間的使用率不佳以及資料同步的問題。當主資料有更新時，那些散佈出去的資料也有可能需要連帶更新。
所以當 pattern 會造成 duplication 時，我們需要考慮：
- 這個資料很常更新嗎？ 不常更新則連帶更新的成本就比較小。
- 會需要即時更新嗎？ 可以忍受過期多久？
2. Staleness (資料過期)
Staleness 是 duplication 的延伸，它是指資料過期的問題。
我們需要考慮的是在各個 use case 下，資料可以過期多久？解決資料過期的方式為週期性更新，那個週期取決於 use case。
例如：
- 上映中的電影票房不用每分鐘更新，1.5~2 小時更新即可。
- 急診室的床位數量可能就需要每 30秒更新一次。
3. Referential Integrity (參照完整性)
Referential Integrity 指的是當我們刪除一筆資料時，它被 reference 的紀錄沒有被刪除，造成在 referencing 時找不到這筆資料。
它的成因和 Staleness 有點關聯。
想像一下今天我們開發的軟體規模很大，各種資料的 collection 分佈在不同的 MongoDB instance 上。當有一筆資料被刪除時，被刪除的資料自己不知道被誰 reference，所以無法即時的將 reference 紀錄刪除。
解決的方法有 2 種：
- 同 staleness：週期性地更新清理。
- 不用 referencing：改用 embedding 來保證生命週期同步。