資料庫存取樹狀架構
Database粗略介紹 Relational Database 關聯式資料庫 RDBMS
情境題
請針對某app產品的資料設計DB structure：
-
每個member（用戶）可以使用多個device進行登入
-
Device登入時會攜帶一筆firebase的device token，作為未來server端使用firebase cloud message（推播功能）的用途
Member
Device
1
多
id
account
password
deviceToken
memberId
客服通知
-
客服通知內會夾帶複數個連結網址
-
每封客服通知都是針對特定的多個用戶製作，只有通知指定的用戶能收到並點開通知內容
Notification
NotificationUrl
1
多
url
notificationId
title
body
id
Member
account
password
id
MemberNotification
memberId
notificationId
但..事總與願違
情境二
- 建立一個留言平台，記錄每個留言（comment）的author
- 每個author都可以針對任何留言開啟thread做回覆
- 記錄每個留言間的層級關係
經典架構面試題
一個層級一張table？
- 層級為動態加入的，無法預測。
- 各個comment的層級數也會動態受到改變
好吧我們從一張table當做切入點去設計
直接加一個欄位紀錄直屬上線的memberId!
或另外建立一個表描述單層上下線關係
adjacency list
- START WITH
- CONNECT BY
- PRIOR
- NOCYCLE
- CONNECT_BY_ISCYCLE
- LEVEL
CONNECT BY + PROIR
LEVEL
START WITH
NOCYCLE
& CONNECT_BY_ISCYCLE
& SYS_CONNECT_BY_PATH
除非你限制了用戶最高下線人數，否則
無法在有限次數的 Query 中得到所有下線的資料。
但是客戶很雞掰，他不會讓你限制這種鳥規定的，他只會覺得你爛
Problem
當專案成長到一定階段，hierarchy model到達一定的水準後，這樣的query便會成為一個效能上的buttleneck
Solutions
1. Path Enumeration column
Fetch comment#7 and its ancestors
Fetch comment#4 and its descendants
透過Expression去解決相關的層級問題
Advantages
- 直觀、節省資料空間
Disadvantages
- 在處理update, delete等操作時較為麻煩
- 完全依賴於expression，SQL code較難理解
- 彈性低，難以提升使用者體驗
2. Create Closure Table
記錄所有的上下層關係（無論層級）
Advantages
- 拆分資料內容本身與對hierarchical model的描述，邏輯較為清晰
- 在修正subtree時擁有非常大的彈性，可以提供更為完整的使用者體驗
- Query, Update, Delete的操作上也容易許多
Disadvantages
- 難以估算需要耗費的資料空間，專案成長時尤其
就是看客戶願不願意吐錢出來
How about NoSQL?
The End!!
謝謝大家～
deck
By ian Lai
