昨天體驗到的維護複雜度，讓洛基一夜難眠，不知道如何在查詢效能和設計複雜度之間找到平衡。

洛基將自己的想法告訴大師：「昨天我深刻體驗到了多視角設計的兩面性。它能提供優秀的查詢效能，但維護複雜度會隨著視角數量急劇增長，請問有好的解決辦法嗎？」

諾斯克點頭：「你已經發現了問題的核心——不是所有查詢都值得建立視角。今天我們要學習的，就是如何系統性地決定哪些查詢值得優化。」

「您是說要建立一套判斷標準？」洛基問。

「正是如此。讓我介紹一個在星際聯盟廣泛使用的分析框架。」大師說。

小行星5020前哨站的實際案例

大師在白板上寫下：

案例背景：小行星5020前哨站活動管理系統
規模設定：
- 日活躍用戶：1000 人
- 每日活動數：約 50 個
- 查詢類型：多樣化的活動查詢需求

設計挑戰：
- 支援多種查詢方式
- 控制維護複雜度
- 在有限資源下做出最佳選擇

「為了做出明智的設計決策，」大師說，「我們需要先分析各種查詢的實際使用情況。」

洛基好奇：「怎麼分析？」

「通過量化分析。」大師回答，「讓我們建立查詢頻率的分級框架。」

查詢頻率分級框架

大師在白板上建立框架：

小行星5020前哨站查詢頻率標準：

核心級 (>100次/天):
- 定義：系統日常運作必需的查詢
- 例：查看今日活動列表 (200個用戶 × 每日2次 = 400次/天)
- 策略：必須用 Query 優化，建立專用視角

重要級 (10-100次/天):
- 定義：重要但非關鍵的查詢
- 例：搜尋特定主題活動 (300個用戶 × 每週搜尋2次 ÷ 7天 ≈ 86次/天)
- 策略：值得考慮優化，視成本決定

一般級 (1-10次/天):
- 定義：偶爾使用的功能查詢
- 例：查看特定日期的活動 (約5次/天)
- 策略：可接受較慢的響應時間

低頻級 (<1次/天):
- 定義：維護或管理用查詢
- 例：產生月度統計報告
- 策略：可使用 Scan，注重成本而非速度

洛基眼睛一亮：「這個框架很清楚！有了具體的數字標準，我就能客觀地分析各種查詢了。」

「但這只是第一步，」大師說，「光有頻率還不夠，我們還需要考慮其他因素。」

多維度分析方法

大師繼續在白板上寫下：

系統性查詢分析的四個維度：

1. 使用頻率 (Frequency)
   - 每日查詢次數
   - 影響：高頻查詢需要優先優化

2. 業務重要性 (Business Impact)
   - 對核心功能的影響程度
   - 影響：重要功能不能太慢

3. 用戶體驗要求 (UX Requirement)
   - 用戶對響應時間的期待
   - 影響：即時性要求高的需要優化

4. 維護成本 (Maintenance Cost)
   - 建立和維護視角的複雜度
   - 影響：成本過高的需要重新考慮

洛基認真記錄：「所以不只是看查詢頻率，還要綜合考慮業務影響、用戶體驗和維護成本？」

「正確！讓我們用實際例子來練習這個分析方法。」

小行星前哨站活動系統的查詢分析

大師展示完整的分析過程：

星際活動系統查詢需求分析：

查詢1: 按星球查詢活動
- 頻率：200個用戶 × 每天2次查看 = 400次/天 (核心級)
- 業務重要性：極高 (主要功能)
- 用戶體驗：即時性要求高 (<100ms)
- 維護成本：低 (單一視角)
→ 決策：必須建立 PLANET# 視角

查詢2: 按主題查詢活動
- 頻率：300個用戶 × 每週搜尋2次 ÷ 7天 = 86次/天 (重要級)
- 業務重要性：高 (重要功能)
- 用戶體驗：可接受較慢 (<300ms)
- 維護成本：低 (單一視角)
→ 決策：值得建立 TOPIC# 視角

查詢3: 按時間查詢活動
- 頻率：約5次/天 (一般級)
- 業務重要性：中 (輔助功能)
- 用戶體驗：可接受慢速 (<1s)
- 維護成本：低 (單一視角)
→ 決策：可建立 DATE# 視角，成本不高

查詢4: 按講者查詢活動
- 頻率：約2次/天 (一般級)
- 業務重要性：低 (非必要功能)
- 用戶體驗：可接受慢速 (<2s)
- 維護成本：低 (單一視角)
→ 決策：可考慮 Scan + Filter，暫不建立視角

查詢5: 按狀態查詢活動
- 頻率：約20次/天 (重要級)
- 業務重要性：中 (管理功能)
- 用戶體驗：可接受較慢 (<500ms)
- 維護成本：高 (狀態變更需要移動資料)
→ 決策：使用 Scan + Filter，避免複雜維護

查詢6: 複合查詢 (星球+主題)
- 頻率：約1次/天 (低頻級)
- 業務重要性：低 (少數需求)
- 用戶體驗：可接受慢速 (<3s)
- 維護成本：極高 (組合爆炸)
→ 決策：使用混合策略 (Query + 後處理)

洛基看著這個分析，恍然大悟：「原來要這樣全面考慮！不是簡單的『建立更多視角』，而是要在效能、複雜度、成本之間找平衡。」

優化後的設計方案

基於分析結果，大師展示最終設計：

小行星前哨站活動系統最佳化設計：

建立的視角 (高效 Query):
1. PLANET# → 支援按星球查詢 (400次/天，核心級)
2. TOPIC# → 支援按主題查詢 (86次/天，重要級)
3. DATE# → 支援按時間查詢 (5次/天，一般級，成本可接受)

使用 Scan + Filter:
4. 按講者查詢 → 頻率低，可接受較慢響應
5. 按狀態查詢 → 維護成本過高，選擇簡單方案

混合策略:
6. 複合查詢 → 先 Query 縮小範圍，再在應用層過濾

洛基計算：「這樣設計的話，一個活動只需要儲存 3 次（加上原始資料可能是 4 次），相比昨天的 15+ 次大幅簡化！」

實際實作優化設計

# 實作最佳化的多視角設計

# 原始資料 (可選：保留一份完整資料供管理使用)
aws dynamodb put-item \
  --table-name IntergalacticEvents \
  --item '{
    "PK": {"S": "EVENT#001"},
    "SK": {"S": "METADATA"},
    "name": {"S": "火星防禦研討會"},
    "planet": {"S": "MARS"},
    "topic": {"S": "Foundation"},
    "speaker": {"S": "Asimov"},
    "date": {"S": "SY210-03-15"},
    "status": {"S": "AVAILABLE"},
    "capacity": {"N": "100"},
    "registered": {"N": "75"}
  }' \
  --endpoint-url http://localhost:8000

# 視角1: 按星球查詢 (核心級 - 必須優化)
aws dynamodb put-item \
  --table-name IntergalacticEvents \
  --item '{
    "PK": {"S": "PLANET#MARS"},
    "SK": {"S": "EVENT#001"},
    "name": {"S": "火星防禦研討會"},
    "topic": {"S": "Foundation"},
    "date": {"S": "SY210-03-15"},
    "status": {"S": "AVAILABLE"}
  }' \
  --endpoint-url http://localhost:8000

# 視角2: 按主題查詢 (重要級 - 值得優化)
aws dynamodb put-item \
  --table-name IntergalacticEvents \
  --item '{
    "PK": {"S": "TOPIC#Foundation"},
    "SK": {"S": "EVENT#001"},
    "name": {"S": "火星防禦研討會"},
    "planet": {"S": "MARS"},
    "date": {"S": "SY210-03-15"},
    "status": {"S": "AVAILABLE"}
  }' \
  --endpoint-url http://localhost:8000

# 視角3: 按時間查詢 (一般級 - 成本可接受)
aws dynamodb put-item \
  --table-name IntergalacticEvents \
  --item '{
    "PK": {"S": "DATE#SY210-03-15"},
    "SK": {"S": "EVENT#001"},
    "name": {"S": "火星防禦研討會"},
    "planet": {"S": "MARS"},
    "topic": {"S": "Foundation"},
    "status": {"S": "AVAILABLE"}
  }' \
  --endpoint-url http://localhost:8000

驗證設計效果

洛基測試新的設計：

# 核心級查詢 - 高效 Query
aws dynamodb query \
  --table-name IntergalacticEvents \
  --key-condition-expression "PK = :pk" \
  --expression-attribute-values '{":pk": {"S": "PLANET#MARS"}}' \
  --endpoint-url http://localhost:8000

# 一般級查詢 - 可接受的 Scan
aws dynamodb scan \
  --table-name IntergalacticEvents \
  --filter-expression "speaker = :speaker" \
  --expression-attribute-values '{":speaker": {"S": "Asimov"}}' \
  --endpoint-url http://localhost:8000

# 混合策略查詢 - Query + 後處理
# 1. 先 Query 按星球查詢
# 2. 在應用層過濾主題
aws dynamodb query \
  --table-name IntergalacticEvents \
  --key-condition-expression "PK = :pk" \
  --expression-attribute-values '{":pk": {"S": "PLANET#MARS"}}' \
  --endpoint-url http://localhost:8000
# (然後在程式中過濾 topic = "Foundation")

洛基有點安心地說：「這個設計既保證了重要查詢的效能，又控制了維護複雜度。更重要的是，我現在有了系統性的決策方法！」

系統性思考的三大原則

大師總結今天的學習：

系統性查詢設計的三大原則：

1. 優先級導向
   - 核心級：必須用 Query 優化
   - 重要級：值得考慮優化
   - 一般級：可接受適度妥協
   - 低頻級：可使用 Scan

2. 多維度分析
   - 不只看頻率，要綜合考慮業務影響、用戶體驗、維護成本
   - 用量化數據指導決策，避免主觀判斷

3. 成本效益平衡
   - 高頻查詢：多花儲存成本，用 Query 優化
   - 低頻查詢：容忍 Scan 的成本
   - 複雜查詢：考慮混合策略或外部工具

「今天你學會了系統性思考。這個框架將成為你未來設計決策的重要工具。明天，我們會深入探討即使有了這套方法，仍然會遇到的技術限制。」

洛基若有所思：「您是指 Query 操作本身還有一些無法克服的限制？」

「正是如此，」大師說，「優秀的設計不僅要有好方法，還要深刻理解工具的邊界。」

Hippo 的課外教學

優先級框架的適用指南

框架適用性評估：

✓ 適合使用的場景：
- 查詢需求明確且相對穩定
- 有足夠的使用數據進行分析
- 團隊有時間進行系統性設計
- 效能要求和成本控制並重

❌ 不適合的場景：
- 查詢需求頻繁變化
- 缺乏真實的使用數據
- 開發時間極度緊迫
- 效能要求不高的內部工具

框架調整建議：
- 根據實際業務調整四個維度的權重
- 定期重新評估查詢優先級
- 監控實際使用情況，驗證分析準確性