Personal SQL Sandbox for Relational Database Design
Skills
Class
Resources
About the Project
Project Overview
A personal SQL sandbox built across four custom databases: gaming_db, MLB_db, f1_db, and brands_db. Each database was designed from scratch using real-world data, structured relationships, and foreign key constraints to demonstrate practical, production-style SQL skills across a range of scenarios, rather than relying on a single pre-built dataset to carry the whole project. Choosing four unrelated domains was deliberate, since it forced every design decision to be made fresh each time, with no shortcuts from reusing a schema that already worked once.
Each database was built independently with its own schema, relationships, and data to reflect distinct real-world domains, gaming, professional baseball, Formula 1 racing, and consumer brands. That independence mattered, since building four unrelated schemas from scratch tests something a single well-worn dataset can't, whether the underlying skill actually transfers or whether it only works within one familiar structure. Each domain came with genuinely different entity relationships, gaming data behaves nothing like racing telemetry, which behaves nothing like brand and product hierarchies.
The project covers core SQL operations applied across varied contexts, moving from foundational queries to relational analysis and aggregation logic. Each domain came with its own natural relationships and edge cases to model correctly, so the sandbox ended up testing schema design judgment as much as query-writing itself, deciding how to normalize each domain's data, where foreign keys actually belonged, and how deep the relational structure needed to go before it stopped adding clarity and started adding unnecessary complexity.
The Issue
Most SQL portfolios rely on a single dataset or pre-built schema, limiting the demonstration of transferable query skills across different data domains and relationship structures. That's a real gap, since writing confident queries against one familiar schema doesn't prove much about whether that same skill holds up against a completely different set of tables, relationships, and data quirks. A portfolio built entirely on one dataset also risks looking like the skill is tied to that specific data, rather than a genuinely portable ability to model and query any relational structure.
The goal was to build a diverse set of databases from scratch to showcase practical SQL proficiency in schema design, relational modeling, and query construction across multiple real-world contexts. Four independent domains meant four independent design decisions, no shortcuts from reusing a schema that already worked once, and no way to fall back on patterns that happened to fit one particular dataset instead of being genuinely reasoned through each time.
Key Objectives
Design and build four relational databases from scratch with structured schemas and foreign key constraints.
Populate each database with real-world data to support meaningful query construction.
Write SQL queries across SELECT, JOIN, subquery, aggregation, and date function operations.
Apply relational logic across distinct domains to demonstrate transferable query skills.
Structure each database to reflect practical data modeling and schema design principles.
Demonstrate consistent, production-style query construction across varied analytical contexts.
My Role & Impact
Database Design
Designed and built four relational databases from scratch with structured schemas and foreign key constraints, each one modeling a genuinely different domain.
Data Population
Populated each database with real-world data to support meaningful query construction and analysis, rather than relying on placeholder or synthetic records.
Query Development
Wrote SQL queries across SELECT, JOIN, subquery, aggregation, and date function operations, applying each technique to the specific structure it made sense for.
Schema Architecture
Structured each database to reflect practical data modeling and schema design principles, treating relationship design as its own skill separate from the querying that came after.
The Process
- Identified four distinct real-world domains, gaming, MLB, Formula 1, and brands, to demonstrate breadth of SQL application, deliberately choosing subjects with different natural relationships rather than four variations on the same underlying structure. Each domain was picked specifically because it would force a different kind of relational thinking, a racing dataset has fundamentally different entity relationships than a product catalog does.
- Designed independent schemas for each database with appropriate relationships and foreign key constraints, working out how each domain's real-world entities actually connected before writing any SQL against them. That meant starting from the actual subject matter each time, what does a game, a player, a team, or a season really relate to, rather than defaulting to a generic schema pattern that happened to work on a previous database.
- Populated databases with real-world data sourced and structured to support meaningful analytical queries, since a schema is only as useful as the data actually sitting inside it when it comes time to query. Real data also surfaces problems a synthetic dataset hides, missing values, inconsistent formatting, edge cases that a clean textbook dataset is specifically built to avoid.
- Developed queries progressing from foundational SELECT operations to complex JOINs, subqueries, and aggregations, then documented query patterns and schema decisions across all four databases to support portfolio presentation. That documentation step mattered as much as the queries themselves, since the point of building four separate databases was proving the reasoning behind each one held up, not just that the SQL happened to execute correctly.
The Solution
Delivered a comprehensive SQL sandbox spanning four custom databases that demonstrates practical, production-style SQL proficiency across diverse real-world domains. Building four independent schemas rather than one meant proving the underlying skill generalized, not just that it worked once against a single familiar dataset, which is a meaningfully higher bar than most single-dataset SQL portfolios are built to clear.
The project strengthened applied SQL skills by working across multiple schemas and data domains rather than a single dataset, building practical experience in database design, foreign key relationships, and real-world data modeling, capabilities directly applicable to data engineering, analytics, and business intelligence roles. It also reinforced a broader habit that shows up across my other work, treating schema and structure decisions as seriously as the queries built on top of them, since a well-designed foundation is usually what separates a query that merely works from one that actually holds up under real use.
Common Questions
Frequently Asked Questions
Four custom databases, four completely different domains, gaming, MLB, Formula 1, and brands, built from scratch as one proof that the underlying SQL skill actually transfers.