在規劃資料庫 schema 時，我們經常會遇到一個問題：「到底要把資料切成幾張表？」有時候，一開始會根據功能把資料拆得很細，讓每個功能對應一張專屬的表。但當系統開始需要跨功能整合，或有某些頁面需要同時查詢多張表時，過多的分表反而會影響效能。這時候，也可以考慮為了讀取效能，在某些情境下設計一張專門給首頁查詢用的冗餘資料表（Denormalized Table），雖然會犧牲寫入效率，但大幅提升查詢速度。這也是軟體工程常說的「沒有銀彈，只有取捨」。
舉個例子：像使用者的「虛擬貨幣餘額」資料，由於更新頻率高、但和其他使用者基本資料無強關聯，這種資料最好獨立一張表。這樣設計的好處有二：
- 可以減少 users table 的鎖定（Lock），避免寫入衝突。
- 可以善用快取（Cache），提升熱門資料的讀取速度。
設計資料表時還有一些常見的 best practice：
- 複合主鍵（Composite key）只在有特定需求時才使用，否則盡量單欄主鍵，便於管理與維護。
- 外鍵（Foreign key）預設都要加 index，加速 JOIN 查詢。例如：
CREATE INDEX idx_user_items_user_id ON user_items(user_id); - 每張表建議都加上
created_at和updated_at欄位，追蹤資料建立與修改時間。為了確保 updated_at 能自動更新，可以用 PostgreSQL 的 trigger：
CREATE OR REPLACE FUNCTION update_updated_at_column()
RETURNS TRIGGER AS $$
BEGIN
NEW.updated_at = CURRENT_TIMESTAMP;
RETURN NEW;
END;
$$ language 'plpgsql';
CREATE TRIGGER update_users_updated_at
BEFORE UPDATE ON users
FOR EACH ROW
EXECUTE FUNCTION update_updated_at_column();玖駿資訊的服務價值
玖駿資訊多年協助各類企業設計與優化資料庫架構，從需求訪談、資料庫正規化（Normalization）、效能調校、快取策略設計，到大型資料遷移與自動備份方案，協助客戶用最有效率的方式解決資料查詢速度、寫入瓶頸、跨系統整合等難題。我們不只追求「正確」的資料設計，更重視在真實商業情境下如何取得最佳的效能和彈性。
玖駿資訊股份有限公司 