當「多對多」變成資料的主角——關係比實體還重要、還會無限延伸——文件與關聯模型都吃力。圖模型把頂點 (vertex) 與邊 (edge) 升為一等公民，讓「關係」本身可被儲存、索引與遍歷。
🧠 Intuition
TIP
一句話分辨：當你的查詢長得像「從這個點出發，沿著關係一直走下去，看能走到哪」（朋友的朋友、零件的零件、誰影響了誰）——這就是圖。關聯模型能存這些關係，但「沿著走」這件事它做得很笨。
- 多對多是圖的母語：社交網路、道路網、知識圖譜——實體間關係縱橫交錯且無固定深度，正是圖模型的甜蜜點。
- 異質性：同一張圖裡可以混不同類型的頂點與邊（人、地點、事件、隸屬、居住、發生於），不必為每種關係開一張表。
- 與文件模型相反：文件擅長樹，圖擅長任意網狀且任意深度的連結。
⚖️ Tradeoffs
Property Graph vs Triple-Store — 兩種圖模型
- Property graph（如 Neo4j）：頂點與邊都是物件，各自可掛任意 key-value 屬性；邊有方向、有標籤。直覺、貼近物件思維。
- Triple-store（如 RDF）：所有資訊拆成
(主詞, 謂詞, 受詞)三元組，例如(Lucy, livesIn, Idaho)。極度均勻、適合資料交換與語意網。 - 表達力大致等價，差在「粒度」：property graph 以節點為中心，triple-store 把一切打散成最小事實單位。
宣告式查詢 — Cypher / SPARQL / Datalog
- Cypher（property graph）：用 ASCII 圖形語法描述路徑模式，如
(person)-[:LIVES_IN]->(loc)，讀起來像在畫圖。 - SPARQL（triple-store / RDF）：對三元組做模式比對，類似 SQL 但天生為圖遍歷設計。
- Datalog（邏輯式）：以規則 (rules) 定義關係，可遞迴組合小規則成複雜查詢，表達力強、組合性好。
- 共通點：你只描述「想要的模式」，遍歷路徑與優化交給引擎——這正是 SQL 在多跳查詢上做不到的。
自然表達任意深度的遍歷
- 「找出所有移居美國、但出生在歐洲的人」——這需要沿
bornIn與livesIn各自往上走到不定深度的地理階層。 - 圖查詢語言對「重複遍歷某種邊 0 到多次」有原生語法（Cypher 的
*0..、SPARQL 的屬性路徑）。 - 深度不固定，正是圖模型相對關聯模型的核心優勢。
為何 SQL 遞迴查詢笨拙
- SQL 的 join 數目必須在查詢撰寫時就寫死；但圖遍歷的跳數往往事先未知。
- 變通是 recursive CTE（
WITH RECURSIVE）——能做到，但語法冗長、難讀難維護、優化器也常力不從心。 - 同一個「朋友的朋友的朋友」查詢，Cypher 幾行搞定，SQL recursive CTE 要寫一大段且效能難料。
- 結論：不是 SQL 做不到，而是它把「不定深度遍歷」這個圖的核心操作，硬塞進為固定 join 設計的語法裡。
🔑 Takeaways
- 圖模型把關係升為一等公民，專治「多對多 + 不定深度遍歷」這類關聯/文件模型啃不動的場景。
- 兩大流派：property graph（節點為中心，Neo4j/Cypher）與 triple-store（事實三元組，RDF/SPARQL）。
- 宣告式查詢（Cypher / SPARQL / Datalog）讓你只描述路徑模式，遍歷與優化交給引擎。
- SQL 不是做不到遞迴，而是 join 數要寫死、recursive CTE 笨重——不定深度遍歷正是圖查詢勝出的地方。
2026-07-01
- Q: 既然關聯模型也能存多對多，什麼時候才真的「需要」圖資料庫？
- A: 分水嶺在遍歷的深度是否固定。多對多但只跳一兩層（如貼文 ↔ 標籤），關聯模型的 join 完全夠用。一旦查詢是「沿著關係走到底、深度事先未知」（朋友的朋友的朋友、供應鏈追溯、權限繼承鏈），SQL 就得動用 recursive CTE，語法與效能都開始痛苦——這時圖模型 + Cypher/SPARQL 的原生遍歷才真正划算。換句話說，是查詢的形狀（不定深度遍歷）逼你選圖，而不只是資料有多對多。