1. 選擇「合併」的情境（適合快照、獨立與高效讀取）
   歷史快照需求：資料需永久保存，不受原始資料後續修改影響（例如：歷史訂單單價、發票客戶地址）。
   讀取效能優先：需頻繁且快速讀取完整資訊，避免複雜的關聯查詢（Joins）。
   資料獨立性高：彼此關聯性低，通常被當作單一獨立實體建立或刪除。
2. 選擇「連結」的情境（適合共用、一致性與彈性維護）
   單一真實來源：子資料頻繁更新，需確保全系統同步（例如：會員基本資料、產品目錄）。
   避免資料冗餘：防止大量重複資料造成儲存浪費或資料不同步風險。
   複雜關聯結構：面對多對多（Many-to-Many）或未來會頻繁變動的關聯關係。

核心原則：追求「查詢快速、需保留歷史」選合併；追求「維護省事、確保資料永遠最新」選連結。

二、 當原始資料異動時，如何進行連動同步？

1. 即時參考與動態查詢（Live Reference / Joins）：僅儲存 ID，每次即時抓取最新內容，無不同步問題（適用同資料庫、高即時性）。
2. 資料庫層級級聯更新（Cascading Updates）：透過資料庫外鍵 ⁠ON UPDATE CASCADE⁠ 自動更新（適用關聯式資料庫）。
3. 事件驅動架構（Event-Driven / Webhooks）：透過訊息佇列通知下游系統更新或清除快取（適用微服務跨系統）。
4. 定期批次同步（Batch Sync / ETL）：透過定時排程批量寫入（適用報表系統、對即時性要求不高的場景）。
   三、 這是 IT 必備知識，還是後續「陪練」出來的？
   底層學理（學校/書籍給予的工具箱）：屬於標準 IT 核心知識（如正規化理論、資料庫設計、系統分析），讓人知道有「合併」與「連結」等選項。
   實務拿捏（職場陪練與踩坑累積）：如何選擇則需要靠實戰經驗。工程師必須在「理論完美」與「現實業務壓力（如報表效能、歷史帳務保存）」之間做出權衡與妥協。
   四、 新人 IT 懂得這些知識的使用時機嗎？
   新人的狀態：通常「知道名詞和技術」，但多半傾向教科書式的理想狀態（例如過度追求正規化、把所有東西都用連結），容易造成系統效能瓶頸或業務需求無法滿足。
   資深的狀態：透過無數次踩坑、挨罵與除錯後，學會在效能、一致性與業務現實中找到平衡，明白「沒有最好的架構，只有最適合當下業務情境的架構」。