postgresql-table-design
設計 PostgreSQL 架構的專家指導
PostgreSQL 架構設計需要了解資料類型、索引策略、約束和效能模式。此技能提供關於 PostgreSQL 特定最佳實踐、進階功能和常見陷阱的全面指導，協助您建立高效、可維護的資料庫架構。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「postgresql-table-design」。 How should I store monetary values in PostgreSQL?
預期結果:
使用 NUMERIC(p,s) 儲存貨幣值，切勿使用浮點類型。例如：amount NUMERIC(10,2) 用於兩位小數的貨幣。這提供精確的十進位運算，避免浮點精度問題。避免使用已棄用的 money 類型。
正在使用「postgresql-table-design」。 What is the difference between BIGINT GENERATED ALWAYS AS IDENTITY and UUID for primary keys?
預期結果:
- BIGINT GENERATED ALWAYS AS IDENTITY：連續整數 ID。適用於大多數情況。優點：儲存空間更小、索引更快、局部性更好。當不需要跨系統的全局唯一性時使用。
- UUID：全局唯一識別符。適用於：合併來自多個資料庫的資料、聯合系統，或需要不透明的非連續 ID。在 PostgreSQL 18+ 使用 uuidv7()，或在較舊版本使用 gen_random_uuid() 產生。
正在使用「postgresql-table-design」。 Should I add indexes on foreign key columns?
預期結果:
是，請務必在外鍵欄位上建立明確索引。與某些資料庫不同，PostgreSQL 不會自動索引外鍵欄位。這可以加速聯結，並防止在刪除或更新父表格時發生鎖定問題。例如：CREATE INDEX ON orders (user_id) 用於 user_id 外鍵。
安全審計
安全This skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.
品質評分
你能建構什麼
設計新的資料庫架構
在為應用程式設計新的 PostgreSQL 資料庫時，取得關於表格結構、資料類型、約束和索引策略的指導。
優化現有架構效能
了解索引策略、分割選項和效能模式，以提升查詢效能並減少資料庫膨脹。
審查架構設計決策
在實作前，根據 PostgreSQL 最佳實踐驗證資料類型選擇、約束使用和正規化決策。
試試這些提示
我需要建立一個使用者表格，包含電子郵件、名稱和時間戳。建議的 PostgreSQL 架構是什麼？
我正在儲存產品價格、IP 位址和使用者偏好設定。應該使用哪些 PostgreSQL 資料類型？
我的訂單表格有依 user_id、狀態和 created_at 過濾的查詢。應該建立哪些索引？
我需要儲存每天數百萬筆感測器讀數，並依設備和時間範圍進行查詢。應該如何設計架構和分割？
最佳實務
- 從正規化到第三正規化的架構開始，僅在對特定高價值查詢測量到效能問題時才進行反正規化
- 對所有時間戳欄位使用 TIMESTAMPTZ，字串使用 TEXT，貨幣使用 NUMERIC，主鍵使用 BIGINT GENERATED ALWAYS AS IDENTITY，除非需要 UUID
- 為 WHERE 子句、JOIN 條件和 ORDER BY 子句中使用的欄位建立索引，並務必在外鍵欄位上建立明確索引
避免
- 不要使用 VARCHAR(n) 或 CHAR(n) 資料類型；如需要長度限制，請使用 TEXT 搭配 CHECK 約束
- 不要使用不含時區的 TIMESTAMP、money 類型或 SERIAL；而是使用 TIMESTAMPTZ、NUMERIC 和 GENERATED ALWAYS AS IDENTITY
- 不要在測量到實際效能問題之前就反正規化資料；過早的反正規化會造成維護負擔，而沒有經證實的益處