/database-schema-design

Design relational or document schemas from access patterns, cardinality, and lifecycle. Use when modeling entities, choosing embed vs normalize, or shaping schema boundaries before implementation.

hoangnguyen0403@hoangnguyen0403

GitHub

From plugin

agent-skills-standard

538200 skills1 MCP

Install

$ npx -y skills add hoangnguyen0403/agent-skills-standard --skill database-schema-design --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/database-schema-design

Context preview

The summary Claude sees to decide when to auto-load this skill.

Design relational or document schemas from access patterns, cardinality, and lifecycle. Use when modeling entities, choosing embed vs normalize, or shaping schema boundaries before implementation.

SKILL.md

database-schema-design.SKILL.md

name: database-schema-design
description: Design relational or document schemas from access patterns, cardinality, and lifecycle. Use when modeling entities, choosing embed vs normalize, or shaping schema boundaries before implementation.
metadata:
  triggers:
    files:
    - '**/*.entity.ts'
    - 'prisma/schema.prisma'
    - '**/*.json'
    keywords:
    - schema
    - data model
    - cardinality
    - embed
    - normalize

Database Schema Design

Priority: P0 (CRITICAL)

Start from reads, writes, and ownership. Schema follows access patterns, not vice versa.

Rules

Model one business concept per table/collection boundary.
Choose embed vs reference or normalize vs denormalize from cardinality, update frequency, and read locality.
Encode uniqueness, nullability, and foreign-key or ownership rules explicitly.
Prefer additive evolution over destructive redesigns.

Verify

[ ] Hot reads are supported without avoidable joins or fan-out.
[ ] Cardinality and lifecycle were written down for major relationships.
[ ] Constraints or validation rules exist for business invariants.
[ ] IDs, timestamps, and soft-delete semantics are consistent.

Anti-Patterns

**No schema from ORM defaults**: model business access patterns first.
**No many-to-many without owner rules**: define source of truth and cleanup behavior.
**No nullable drift**: nullable fields need lifecycle meaning.