softaworks/agent-toolkit/database-schema-designer

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.

Install

npx vskill@latest install softaworks/agent-toolkit/database-schema-designer

SKILL.md

Database Schema Designer

Design production-ready database schemas with best practices built-in.


Quick Start

Just describe your data model:

design a schema for an e-commerce platform with users, products, orders

You'll get a complete SQL schema like:

sql
CREATE TABLE users (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE orders (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_id BIGINT NOT NULL REFERENCES users(id),
total DECIMAL(10,2) NOT NULL,
INDEX idx_orders_user (user_id)
);

What to include in your request:

  • Entities (users, products, orders)
  • Key relationships (users have orders, orders have items)
  • Scale hints (high-traffic, millions of records)
  • Database preference (SQL/NoSQL) - defaults to SQL if not specified

Triggers

TriggerExample
design schema"design a schema for user authentication"
database design"database design for multi-tenant SaaS"
create tables"create tables for a blog system"
schema for"schema for inventory management"
model data"model data for real-time analytics"
I need a database"I need a database for tracking orders"
design NoSQL"design NoSQL schema for product catalog"

Key Terms

TermDefinition
NormalizationOrganizing data to reduce redundancy (1NF → 2NF → 3NF)
3NFThird Normal Form - no transitive dependencies between columns
OLTPOnline Transaction Processing - write-heavy, needs normalization
OLAPOnline Analytical Processing - read-heavy, benefits from denormalization
Foreign Key (FK)Column that references another table's primary key
IndexData structure that speeds up queries (at cost of slower writes)
Access PatternHow your app reads/writes data (queries, joins, filters)
DenormalizationIntentionally duplicating data to speed up reads

Quick Reference

TaskApproachKey Consideration
New schemaNormalize to 3NF firstDomain modeling over UI
SQL vs NoSQLAccess patterns decideRead/write ratio matters
Primary keysINT or UUIDUUID for distributed systems
Foreign keysAlways constrainON DELETE strategy critical
IndexesFKs + WHERE columnsColumn order matters
MigrationsAlways reversibleBackward compatible first

Process Overview

Your Data Requirements
|
v
+-----------------------------------------------------+
| Phase 1: ANALYSIS |
| * Identify entities and relationships |
| * Determine access patterns (read vs write heavy) |
| * Choose SQL or NoSQL based on requirements |
+-----------------------------------------------------+
|
v
+-----------------------------------------------------+
| Phase 2: DESIGN |
| * Normalize to 3NF (SQL) or embed/reference (NoSQL) |
| * Define primary keys and foreign keys |
| * Choose appropriate data types |
| * Add constraints (UNIQUE, CHECK, NOT NULL) |
+-----------------------------------------------------+
|
v
+-----------------------------------------------------+
| Phase 3: OPTIMIZE |
| * Plan indexing strategy |
| * Consider denormalization for read-heavy queries |
| * Add timestamps (created_at, updated_at) |
+-----------------------------------------------------+
|
v
+-----------------------------------------------------+
| Phase 4: MIGRATE |
| * Generate migration scripts (up + down) |
| * Ensure backward compatibility |
| * Plan zero-downtime deployment |
+-----------------------------------------------------+
|
v
Production-Ready Schema

Commands

CommandWhen to UseAction
design schema for {domain}Starting freshFull schema generation
normalize {table}Fixing existing tableApply normalization rules
add indexes for {table}Performance issuesGenerate index strategy
migration for {change}Schema evolutionCreate reversible migration
review schemaCode reviewAudit existing schema

Workflow: Start with design schema → iterate with normalize → optimize with add indexes → evolve with migration


Core Principles

PrincipleWHYImplementation
Model the DomainUI changes, domain doesn'tEntity names reflect business concepts
Data Integrity FirstCorruption is costly to fixConstraints at database level
Optimize for Access PatternCan't optimize for bothOLTP: normalized, OLAP: denormalized
Plan for ScaleRetrofitting is painfulIndex strategy + partitioning plan

Anti-Patterns

AvoidWhyInstead
VARCHAR(255) everywhereWastes storage, hides intentSize appropriately per field
FLOAT for moneyRounding errorsDECIMAL(10,2)
Missing FK constraintsOrphaned dataAlways define foreign keys
No indexes on FKsSlow JOINsIndex every foreign key
Storing dates as stringsCan't compare/sortDATE, TIMESTAMP types
SELECT * in queriesFetches unnecessary dataExplicit column lists
Non-reversible migrationsCan't rollbackAlways write DOWN migration
Adding NOT NULL without defaultBreaks existing rowsAdd nullable, backfill, then constrain

Verification Checklist

After designing a schema:

  • [ ] Every table has a primary key
  • [ ] All relationships have foreign key constraints
  • [ ] ON DELETE strategy defined for each FK
  • [ ] Indexes exist on all foreign keys
  • [ ] Indexes exist on frequently queried columns
  • [ ] Appropriate data types (DECIMAL for money, etc.)
  • [ ] NOT NULL on required fields
  • [ ] UNIQUE constraints where needed
  • [ ] CHECK constraints for validation
  • [ ] created_at and updated_at timestamps
  • [ ] Migration scripts are reversible
  • [ ] Tested on staging with production data

<details> <summary><strong>Deep Dive: Normalization (SQL)</strong></summary>

Normal Forms
FormRuleViolation Example
1NFAtomic values, no repeating groupsproduct_ids = '1,2,3'
2NF1NF + no partial dependenciescustomer_name in order_items
3NF2NF + no transitive dependenciescountry derived from postal_code
1st Normal Form (1NF)
sql
-- BAD: Multiple values in column
CREATE TABLE orders (
id INT PRIMARY KEY,
product_ids VARCHAR(255) -- '101,102,103'
);
-- GOOD: Separate table for items
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT
);
CREATE TABLE order_items (
id INT PRIMARY KEY,
order_id INT REFERENCES orders(id),
product_id INT
);
2nd Normal Form (2NF)
sql
-- BAD: customer_name depends only on customer_id
CREATE TABLE order_items (
order_id INT,
product_id INT,
customer_name VARCHAR(100), -- Partial dependency!
PRIMARY KEY (order_id, product_id)
);
-- GOOD: Customer data in separate table
CREATE TABLE customers (
id INT PRIMARY KEY,
name VARCHAR(100)
);
3rd Normal Form (3NF)
sql
-- BAD: country depends on postal_code
CREATE TABLE customers (
id INT PRIMARY KEY,
postal_code VARCHAR(10),
country VARCHAR(50) -- Transitive dependency!
);
-- GOOD: Separate postal_codes table
CREATE TABLE postal_codes (
code VARCHAR(10) PRIMARY KEY,
country VARCHAR(50)
);
When to Denormalize
ScenarioDenormalization Strategy
Read-heavy reportingPre-calculated aggregates
Expensive JOINsCached derived columns
Analytics dashboardsMaterialized views
sql
-- Denormalized for performance
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT,
total_amount DECIMAL(10,2), -- Calculated
item_count INT -- Calculated
);

</details>

<details> <summary><strong>Deep Dive: Data Types</strong></summary>

String Types
TypeUse CaseExample
CHAR(n)Fixed lengthState codes, ISO dates
VARCHAR(n)Variable lengthNames, emails
TEXTLong contentArticles, descriptions
sql
-- Good sizing
email VARCHAR(255)
phone VARCHAR(20)
country_code CHAR(2)
Numeric Types
TypeRangeUse Case
TINYINT-128 to 127Age, status codes
SMALLINT-32K to 32KQuantities
INT-2.1B to 2.1BIDs, counts
BIGINTVery largeLarge IDs, timestamps
DECIMAL(p,s)Exact precisionMoney
FLOAT/DOUBLEApproximateScientific data
sql
-- ALWAYS use DECIMAL for money
price DECIMAL(10, 2) -- $99,999,999.99
-- NEVER use FLOAT for money
price FLOAT -- Rounding errors!
Date/Time Types
sql
DATE -- 2025-10-31
TIME -- 14:30:00
DATETIME -- 2025-10-31 14:30:00
TIMESTAMP -- Auto timezone conversion
-- Always store in UTC
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
Boolean
sql
-- PostgreSQL
is_active BOOLEAN DEFAULT TRUE
-- MySQL
is_active TINYINT(1) DEFAULT 1

</details>

<details> <summary><strong>Deep Dive: Indexing Strategy</strong></summary>

When to Create Indexes
Always IndexReason
Foreign keysSpeed up JOINs
WHERE clause columnsSpeed up filtering
ORDER BY columnsSpeed up sorting
Unique constraintsEnforced uniqueness
sql
-- Foreign key index
CREATE INDEX idx_orders_customer ON orders(customer_id);
-- Query pattern index
CREATE INDEX idx_orders_status_date ON orders(status, created_at);
Index Types
TypeBest ForExample
B-TreeRanges, equalityprice > 100
HashExact matches onlyemail = 'x@y.com'
Full-textText searchMATCH AGAINST
PartialSubset of rowsWHERE is_active = true
Composite Index Order
sql
CREATE INDEX idx_customer_status ON orders(customer_id, status);
-- Uses index (customer_id first)
SELECT * FROM orders WHERE customer_id = 123;
SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending';
-- Does NOT use index (status alone)
SELECT * FROM orders WHERE status = 'pending';

Rule: Most selective column first, or column most queried alone.

Index Pitfalls
PitfallProblemSolution
Over-indexingSlow writesOnly index what's queried
Wrong column orderUnused indexMatch query patterns
Missing FK indexesSlow JOINsAlways index FKs

</details>

<details> <summary><strong>Deep Dive: Constraints</strong></summary>

Primary Keys
sql
-- Auto-increment (simple)
id INT AUTO_INCREMENT PRIMARY KEY
-- UUID (distributed systems)
id CHAR(36) PRIMARY KEY DEFAULT (UUID())
-- Composite (junction tables)
PRIMARY KEY (student_id, course_id)
Foreign Keys
sql
FOREIGN KEY (customer_id) REFERENCES customers(id)
ON DELETE CASCADE -- Delete children with parent
ON DELETE RESTRICT -- Prevent deletion if referenced
ON DELETE SET NULL -- Set to NULL when parent deleted
ON UPDATE CASCADE -- Update children when parent changes
StrategyUse When
CASCADEDependent data (order_items)
RESTRICTImportant references (prevent accidents)
SET NULLOptional relationships
Other Constraints
sql
-- Unique
email VARCHAR(255) UNIQUE NOT NULL
-- Composite unique
UNIQUE (student_id, course_id)

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Installs
1
Repository stars
1,222
Repository forks
96
7-day trend score
38

Installs come from the vskill CLI. Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 20 Mar 2026, 7 months ago.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/softaworks/agent-toolkit/database-schema-designer/badge)](https://verified-skill.com/skills/softaworks/agent-toolkit/database-schema-designer)

Something wrong with this skill or its page? Tell us.