一键导入
database-design
Schema design, migrations, indexing, and query patterns for maintainable and performant databases
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Schema design, migrations, indexing, and query patterns for maintainable and performant databases
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | database-design |
| description | Schema design, migrations, indexing, and query patterns for maintainable and performant databases |
| difficulty | senior |
| domains | ["general"] |
Database schemas are among the hardest things to change in a production system. Migrations run during live traffic. Indexes affect every query. Schema choices made today constrain options for years. This skill gets them right from the start.
Understand the access patterns before normalizing. Which queries are in the critical path? What are the read/write ratios? This drives index and schema decisions.
Start with a normalized design. Denormalize only when profiling shows it's necessary, and document why.
Every migration must be backward compatible with the current code:
Never drop a column in the same deploy that stops using it.
Index columns that appear in WHERE clauses, JOIN conditions, and ORDER BY of hot queries. Don't over-index — each index slows writes.
Run EXPLAIN on every hot query before deploying.
For audit trails, compliance, or reference integrity: use soft deletes (deleted_at timestamp). For data that must be truly erased (GDPR): implement hard delete + audit log.
Every table should have: created_at, updated_at. Tables with audit requirements: created_by, updated_by.
Test every migration against a production-size dataset:
EXPLAIN run