圖形資料庫如何儲存「按讚」的時間和裝置資訊？
原題
在圖形資料庫（Graph Database）中建模社群平台資料時，若每筆「按讚」行為都包含時間戳記（Timestamp）與裝置類型（Device Type）等資訊。若希望同時保留使用者與貼文之間的互動關係，並能有效查詢「按讚」的行為屬性，下列哪一種設計方式最為合適？
白話
要用圖形資料庫（Graph Database）建模社群平台，其中「按讚」這個行為附帶了時間和裝置資訊。目標是同時保留「用戶和貼文之間的按讚關係」，並且能查詢這筆按讚的屬性（何時、用什麼裝置）。
問你：在圖形資料庫裡，帶屬性的「按讚」互動該怎麼設計？
先自己選一個答案，再看完整解析。
一句話總結
在圖形資料庫裡，帶屬性的互動行為（如按讚附帶時間和裝置）：應把互動當成帶屬性的邊（Edge/Relationship），把時間戳記和裝置類型存在邊的屬性裡，邊連結用戶節點和貼文節點。
情境
先感受問題：按讚不只是「有沒有按」
「連動社群」平台的工程師志遠要設計一個圖形資料庫，記錄用戶和貼文的按讚關係。
問題是：每次按讚不只是「用戶 A 按了貼文 X 的讚」，還附帶資訊：
時間戳記：2025-03-15 14:32:07
裝置類型：iOS App
按讚類型：愛心
這些附帶資訊要怎麼存？存在哪裡？怎麼設計才能快速查詢「這個按讚是哪台裝置、什麼時候按的」？
舊方法
亂放按讚資訊會有什麼問題
- 存進用戶節點，用戶節點膨脹：把「用戶 A 按讚的所有記錄」全存進用戶節點，一個用戶按了 10 萬個讚，節點就有 10 萬筆資料，查詢速度大幅下降，且跟「用戶個人資料」混在一起結構混亂。
- 把按讚當獨立節點，查詢要多跳一層：若「按讚」是節點，需要「用戶→按讚→貼文」兩層跳轉，比「用戶→（按讚）→貼文」一層跳轉多一步，查詢複雜且效能較差。
- 放進關聯式資料庫，失去圖的優勢：圖形資料庫的強項是快速走訪多層關係，放進 RDBMS 後，「誰按過和某人相同帖子的讚」這類查詢就需要多次 JOIN，效能不佳。
- 不知道邊可以有屬性：許多人知道節點可以有屬性，但忘了圖形資料庫的邊（Relationship）也可以有屬性，導致設計繞路。
- 屬性放錯地方，查詢語義混亂：若把按讚的裝置類型存進貼文節點，「查詢某貼文被哪些裝置按過」就跟「查詢貼文本身的屬性」混在一起，語義不清晰。
新方法
按讚當邊，時間和裝置掛在邊的屬性上
志遠採用「帶屬性的關係邊」設計：
節點：User（用戶 A）
節點：Post（貼文 X）
邊：LIKED（用戶 A 按讚貼文 X）
邊的屬性 timestamp: 2025-03-15 14:32:07
邊的屬性 device_type: iOS App
邊的屬性 reaction_type: 愛心
這樣的設計讓查詢非常直觀：「找出用戶 A 在 iOS 上按讚的所有貼文」只需要沿著邊走，過濾邊的屬性 device_type='iOS'。關係和屬性都在一起，既保留了圖的連結語義，又能附加行為細節。
這就是選項 B 講的：將「按讚」資訊作為邊的屬性（Property）儲存，連結使用者與被按讚的貼文節點。
圖形資料庫（如 Neo4j）採用「屬性圖模型（Property Graph Model）」，其中節點和邊都可以攜帶屬性（key-value 對）。這是和 RDF 三元組模型的主要差異之一。
Neo4j 的 Cypher 查詢語法示範（讀取概念即可，不需背語法）：
建立帶屬性的邊：
MATCH (u:User {id:'userA'}), (p:Post {id:'post1'})
CREATE (u)-[:LIKED {timestamp:'2025-03-15', device:'iOS'}]->(p)
查詢「用戶 A 在 iOS 上按讚的所有貼文」：
MATCH (u:User {id:'userA'})-[r:LIKED {device:'iOS'}]->(p:Post) RETURN p
邊屬性讓圖形資料庫可以表達豐富的互動語義，在社交網路、推薦系統、知識圖譜建模中廣泛使用。相對地，如果按讚行為的屬性非常複雜（例如需要再細分多層），有時也會使用「中間節點（Intermediate Node）」設計，把按讚本身變成一個節點，但這增加了查詢複雜度，通常不是首選。
錯選項
為什麼其他選項是錯的
A將「按讚」視為節點（Node），與使用者建立邊（Edge）
字面在說什麼
把「按讚」設計成一個獨立節點，然後用戶和這個節點之間有一條邊。
為什麼不對
這個設計把「用戶→按讚節點→貼文」拆成兩層，查詢和走訪要多一步。更關鍵的是，這樣的設計缺乏了「按讚連結用戶和貼文」的直接語義，圖的結構語義變模糊。只有當按讚需要連接到其他多個節點（如按讚後又觸發了評論、獎勵等複雜關係）時，才考慮把它升格為節點。
誰會選錯
認為「有屬性的東西一定要當節點」的人，不知道圖形資料庫的邊也可以帶屬性。
C把「按讚」資訊直接寫入使用者節點中作為屬性
字面在說什麼
用戶節點上加一個屬性叫「按讚紀錄」，把所有按讚資訊存進去。
為什麼不對
用戶節點會無限膨脹（按 10 萬個讚就有 10 萬筆），且按讚紀錄和用戶個人資料混雜，結構不清。圖形資料庫的節點應該是「實體」（用戶本身），不應把「行為」塞進去。
誰會選錯
把「NoSQL 文件型資料庫把所有資訊嵌入同一文件」的思路套到圖形資料庫設計上的人。
D建立「按讚紀錄表」並將資料存入關聯式資料庫
字面在說什麼
不用圖形資料庫設計，改回關聯式資料庫建表處理。
為什麼不對
題目明確在問「圖形資料庫中的設計方式」，這個選項直接放棄圖形資料庫、換成 RDBMS，完全偏離題目要求。再者，關聯式資料庫對社群網路多層關係查詢需要多次 JOIN，效能遠不如圖形資料庫。
誰會選錯
對圖形資料庫設計不熟悉，直覺回到熟悉的 SQL 關聯式資料庫的人。
變形題
同個考點下次怎麼變形
按讚當邊就好，那什麼時候要當節點？
答案
當這個行為需要連接到「兩個以上的其他節點」時，就需要升格為節點。例如：「訂單」連接了用戶、商品、配送員、優惠券，因為有四個連接對象，所以「訂單」是節點，而不是用戶和商品之間的邊。
節點和邊各代表什麼，什麼東西該放在哪裡？
答案
節點代表「實體」（Entity），如用戶、貼文、商品；邊代表「關係」（Relationship），如按讚、追蹤、購買。兩者都可以有屬性（Property），但屬性的語義要符合它所在的概念層次。
圖形資料庫和關聯式資料庫都可以存社群資料，為什麼要選圖形？
答案
圖形資料庫在「多層關係走訪」上效能遠優於 RDBMS。「朋友的朋友的朋友」這類三層以上的關係查詢，RDBMS 需要多次 JOIN，時間複雜度急劇上升；圖形資料庫直接沿邊走訪，效能穩定。
圖形資料庫有很多種，RDF 和屬性圖不一樣嗎？
答案
RDF 三元組（主語-述語-賓語）的邊本身不能直接帶屬性，要加屬性需要額外三元組或具名圖；屬性圖模型（Neo4j 使用）的節點和邊都可以直接掛屬性，對本題這種「互動帶屬性」的需求，屬性圖更直接簡潔。
知識圖譜也用圖形資料庫，跟社群平台的圖資料庫一樣嗎？
答案
知識圖譜重視語意明確性和本體論（Ontology），常用 RDF + OWL 標準，邊的類型代表語義關係（如 is-a、part-of）；社群平台圖資料庫重視效能和靈活查詢，常用屬性圖模型，邊代表具體互動（按讚、追蹤、留言）。前者強調推理，後者強調查詢效率。
延伸