Game Resource Vertical Table¶
概念概覽
垂直資源表設計模式¶
核心知識¶
垂直資源表設計模式¶
純餘額型資源（Gold、Diamond、DungeonToken）與池型資源（Stamina，含上限 + 恢復計時）的混用是語義汙染的根源，應拆為兩張表：
player_resources：type 欄位區分資源種類，新增任何 ResourcesType（8/9/10…）完全不需要改 code 或做 migrationplayer_resource_pools：池型資源專屬，紀錄 max、recover_at 等欄位
核心高頻貨幣的特殊要求¶
DungeonToken 屬於每局都會產出/消耗的核心貨幣，必須走實體欄位 + CAS（Compare-And-Swap） + CHECK 約束防超扣，不可用 JSONB extra_currencies 儲存（JSONB 無法做 CAS）。
遷移策略¶
垂直表的代價是 JOIN 查詢複雜度略增；橫向欄位直覺但每次新增資源都要 ALTER TABLE，長期維護成本更高。
經驗教訓¶
-
垂直資源表的 type 欄位設計讓資源種類擴充完全不需要 migration，是降低長期維護成本的核心決策
-
核心高頻貨幣必須走實體欄位 + CAS，JSONB 無法提供 CAS 與 CHECK 約束保護
-
遷移時分 Phase 執行並保留雙寫，確保每個階段都可 rollback
常見陷阱¶
-
將池型資源（Stamina）與純餘額型資源（Gold）放同一張表，導致語義不清且難以分別加約束
-
用 JSONB 儲存高頻核心貨幣（DungeonToken），失去 CAS 防超扣能力
最佳實踐¶
-
所有新增遊戲資源預設進 player_resources 垂直表，評估後才考慮 pool 型
-
schema 加清楚的 COMMENT 說明每張表的設計意圖
-
核心高頻貨幣（每局都會扣除的）必須走實體欄位 + CAS
相關概念¶
- gRPC Proto Pool Resource Design
- Hero Unlock Idempotency
- MatchRPG Unlimited Constants DB Cap Strategy
- PendingEvents Middleware Pattern for Real-time HUD
- PostgreSQL JSONB Hot Predicate Anti-pattern
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Pool Resource Stamina Routing — 共享：
game-backend/ 獨特：honest-boundary,pool-resource - Game Item Exemption Resource Architecture — 共享：
game-backend/ 獨特：architecture-pattern,item-system - Reward Claims Architecture — 共享：
game,schema/ 獨特：game-server,reward-system
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-19 | 04c2b73d-c00e-4eaf-959f-0dbf0f224e24 | 確立了將混用的 player_currencies 拆分為 player_resources（純餘額型）與 player_resource_pools（池型）的設計決策與取捨依據 |