資料庫 schema 設計錯誤會導致效能問題與資料完整性問題。此技能提供 PostgreSQL 專用的最佳實踐，涵蓋資料類型、索引、條件約束與擴展性模式。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「postgresql」。 設計一個包含 email、name 與 timestamps 的 users 資料表
預期結果:
- CREATE TABLE users (
- user_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
- email TEXT NOT NULL UNIQUE,
- name TEXT NOT NULL,
- created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
- updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
- );
- CREATE UNIQUE INDEX ON users (LOWER(email));
正在使用「postgresql」。 我應該使用 UUID 還是 BIGINT 作為主鍵？
預期結果:
- 在以下情況使用 BIGINT GENERATED ALWAYS AS IDENTITY：
- - 循序 ID 可接受
- - 索引效能至關重要
- - 較小的索引大小很重要
- 在以下情況使用 UUID：
- - 需要全域唯一性
- - ID 不透明性是安全性需求
- - 需要合併來自多個來源的資料
安全審計
安全All 221 static analyzer findings were determined to be false positives. The skill consists entirely of markdown documentation (SKILL.md) with no executable code. Backtick characters are markdown formatting for code examples, not shell execution. References to security features like Row Level Security are PostgreSQL documentation, not Windows SAM access. The skill provides educational guidance for database schema design with no security risks.
品質評分
你能建構什麼
新應用���式 Schema 設計
為新的網頁應用程式設計完整的資料庫 schema，包含適當的資料類型、主鍵、外部鍵關聯，以及常見查詢模式的索引。
Schema 審查與最佳化
審查現有的資料表設計，檢查效能問題、缺少的索引、不當的資料類型，或可能導致資料完整性問題的條件約束缺口。
遷移規劃
使用交易式 DDL、並發索引建立，以及在無停機機況下為大型資料表新增資料行的策略，規劃安全的 schema 演進。
試試這些提示
設計一個用於儲存使用者檔案的 PostgreSQL 資料表，包含 email、name、registration date 與選用性的 profile settings 欄位。使用適當的資料類型與條件約束。
我有一個 queries 資料表，包含欄位：id、user_id、status、created_at。常見查詢會依 user_id 與 status 進行篩選，並按 created_at 降序排序。請推薦索引策略。
我應該將產品屬性儲存在 JSONB 欄位還是建立獨立欄位？屬性因產品類別而異，且使用者經常依特定屬性搜尋。
我有一個 events 資料表，每月成長 1000 萬筆資料列。查詢通常依 event_date 與 device_id 進行篩選。請推薦分割策略並說明取捨。
最佳實務
- 對所有事件時間戳使用 TIMESTAMPTZ 而非 TIMESTAMP，以避免時區混淆
- 為外部鍵欄位新增明確索引，因為 PostgreSQL 不會自動建立
- 先正規化至 3NF，然後僅在證明高 ROI 的讀取效能提升時再進行反正規化
避免
- 使用帶有長度限制的 VARCHAR，而非使用帶有 CHECK 條件約束的 TEXT
- 在未分析實際查詢模式的情況下為每個欄位建立索引
- 對自動遞增欄位使用 SERIAL 而非 GENERATED ALWAYS AS IDENTITY