# 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.

- Skill: `hoangnguyen0403/database-schema-design` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add hoangnguyen0403/database-schema-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hoangnguyen0403/database-schema-design/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: HoangNguyen0403 (https://skillmd.com/u/hoangnguyen0403)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/hoangnguyen0403/database-schema-design

---

# 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.

## References

- [Framework Map](../references/framework-map.md)
- [Normalization Tradeoffs](references/normalization-tradeoffs.md)