# Design Reliable Database Schemas

Poor schemas create slow queries, fragile migrations, and inconsistent data. This skill guides Claude, Codex, and Claude Code through practical schema design decisions.

## Install

```bash
npx skillstore add ai agent hub/ariegoldkin-database-schema-designer
```

## Metadata

- - Status: approved
- - Slug: ariegoldkin-database-schema-designer
- - Version: 1.0.0
- - Author: AI Agent Hub
- - GitHub username: ArieGoldkin
- - License: MIT
- - Repository: https://github.com/ArieGoldkin/ai-agent-hub/tree/main/skills/database-schema-designer
- - Ref: main
- - Supported tools: Claude, Codex, Claude Code
- - Risk level: low
- - Quality score: 76
- - Public page: https://skillstore.pages.dev/skills/ariegoldkin-database-schema-designer
- - Manifest: https://skillstore.pages.dev/api/skills/ariegoldkin-database-schema-designer/manifest

## Capabilities

- Explains normalization from 1NF through 3NF with practical table examples.
- Compares embedding and referencing for document database models.
- Recommends primary keys, foreign keys, constraints, and data types.
- Provides indexing guidance for relational databases and MongoDB collections.
- Outlines reversible and zero-downtime migration patterns.
- Includes a schema review checklist and migration template.

## Use Cases

- Plan a New Product Database: Define entities, relationships, keys, constraints, and initial indexes before implementation begins.
- Review a Migration Plan: Check whether schema changes are reversible, staged, and safe for production rollout.
- Choose SQL or NoSQL Modeling: Compare normalized relational models with embedded or referenced document models for known access patterns.

## Prompt Templates

### Design a Basic Schema

```
Design a database schema for [application]. Include entities, relationships, primary keys, foreign keys, and important constraints.
```

### Review an Existing Schema

```
Review this schema for normalization, indexes, constraints, and migration risks. Explain the top changes I should make first: [schema summary].
```

### Plan a Safe Migration

```
Create a safe migration plan for changing [old structure] to [new structure]. Include rollout steps, rollback steps, validation checks, and downtime risks.
```

### Optimize for Access Patterns

```
Given these access patterns and data volumes, propose SQL or NoSQL schema changes, indexes, partitioning options, and tradeoffs: [details].
```

## Limitations

- Does not connect to live databases or inspect existing schemas automatically.
- Does not generate database-specific syntax for every SQL dialect.
- Requires user-provided entities, access patterns, and scale requirements.
- Does not replace review by a database administrator for production migrations.

## Best Practices

- Start with entities, relationships, and access patterns before choosing indexes or storage technology.
- Document every denormalization, index, and migration step with the reason it exists.
- Test migrations on realistic data and include rollback and validation steps.

## Anti Patterns

- Do not choose NoSQL only to avoid modeling relationships that actually need integrity checks.
- Do not add indexes to every column without measuring read and write tradeoffs.
- Do not make breaking schema changes without a staged application rollout plan.

## Security Audit

- - Safe to publish: true
- - Audited at: 2026-06-28T09:45:15.258\+00:00
- - Summary: Static analysis reported weak cryptography, system reconnaissance, and Ruby backtick execution patterns. Manual review found these are false positives from database terminology, SQL metadata queries, and Markdown fenced examples rather than executable behavior. One low-severity content issue remains because a negative Python example uses SQL string interpolation without calling out injection risk.

## Stats

- - Views: 205
- - Downloads: 9
- - Favorites: 0
- - Popularity score: 0
