技能 postgresql
📦

postgresql

安全

設計 PostgreSQL 資料庫 Schema

也可从以下获取: 2025Emma,2025Emma

資料庫 schema 設計錯誤會導致效能問題與資料完整性問題。此技能提供 PostgreSQL 專用的最佳實踐,涵蓋資料類型、索引、條件約束與擴展性模式。

支持: Claude Codex Code(CC)
📊 71 充足
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“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 不透明性是安全性需求
  • - 需要合併來自多個來源的資料

安全审计

安全
v1 • 2/24/2026

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.

1
已扫描文件
233
分析行数
0
发现项
1
审计总数
未发现安全问题
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
32
社区
100
安全
91
规范符合性

你能构建什么

新應用���式 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 設計決策
我應該將產品屬性儲存在 JSONB 欄位還是建立獨立欄位?屬性因產品類別而異,且使用者經常依特定屬性搜尋。
大型資料表分割
我有一個 events 資料表,每月成長 1000 萬筆資料列。查詢通常依 event_date 與 device_id 進行篩選。請推薦分割策略並說明取捨。

最佳实践

  • 對所有事件時間戳使用 TIMESTAMPTZ 而非 TIMESTAMP,以避免時區混淆
  • 為外部鍵欄位新增明確索引,因為 PostgreSQL 不會自動建立
  • 先正規化至 3NF,然後僅在證明高 ROI 的讀取效能提升時再進行反正規化

避免

  • 使用帶有長度限制的 VARCHAR,而非使用帶有 CHECK 條件約束的 TEXT
  • 在未分析實際查詢模式的情況下為每個欄位建立索引
  • 對自動遞增欄位使用 SERIAL 而非 GENERATED ALWAYS AS IDENTITY

常见问题

我應該對字串欄位使用 TEXT 還是 VARCHAR?
在大多數情況下使用 TEXT。PostgreSQL 以相同方式儲存 TEXT 與 VARCHAR。如果您需要長度驗證,請新增 CHECK 條件約��,而非使用 VARCHAR(n)。
我需要為外部鍵欄位建立索引嗎?
是的。PostgreSQL 不會自動為 FK 欄位建立索引。請為 FK 欄位新增明確索引,以提升 join 效能並防止刪除父資料列時的鎖定問題。
何時應該使用 JSONB 而非一般欄位?
對選用、可變或半結構化屬性使用 JSONB。將核心關聯式資料保留在一般欄位中。請務必為 JSONB 欄位新增 GIN 索引以進行包含查詢。
TIMESTAMP 與 TIMESTAMPTZ 有什麼差異?
TIMESTAMPTZ 儲存具備時區意識的時間戳,並在內部轉換為 UTC。TIMESTAMP 儲存不具時區上下文的字面值。請始終使用 TIMESTAMPTZ 以避免時區錯誤。
我應該分割我的資料表嗎?
當資料表超過 1 億筆資料列,且查詢始終依分割鍵(如日期)進行篩選時,請考慮分割。分割會增加複雜度,因此僅在存在明確效益時使用。
如何安全地為大型資料表新增 NOT NULL 欄位?
先將欄位新增為 NULL,回填���料,然後變更為 NOT NULL。新增帶有 volatile 預設值(如 now())的 NOT NULL 會導致完整資料表重寫。請使用 non-volatile 預設值或多步驟遷��。

开发者详情

文件结构

📄 SKILL.md