Wrapping Up My SQL Track and Starting Database Design & Data Modeling

Today I wrapped up the SQL learning track I started back at the end of July. Looking at my blog archive now, it’s wild to see how something that started as a port conflict on my Mac turned into nine posts covering everything from basic table creation to window functions, CTEs, views, and stored procedures.

How This Whole Track Started

When I first spun up a MySQL container in Docker on port 3307, my goal was pretty simple: stop treating SQL like something I only touched through an ORM when a backend project forced me to, and actually learn the language properly from the ground up.

Instead of just watching a tutorial at 1.5x speed and nodding along, I decided to write down every single stage on my website as I practiced it in MySQL Workbench:

1. SQL Basics Part 1: DDL, DML, Constraints & Keys: Building databases and tables from scratch, understanding DDL vs. DML, and finally getting clear on Primary, Foreign, Candidate, Alternate, Composite, and Surrogate keys.
2. SQL Basics Part 2: SELECT, WHERE, Sorting, and GROUP BY: Filtering rows, learning the difference between WHERE and HAVING, and discovering the logical execution order (FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY -> LIMIT) that explains half of SQL’s “weird” rules.
3. SQL Basics Part 3: INNER JOIN, LEFT JOIN, RIGHT JOIN, UPDATE, and DELETE: Connecting mismatched tables with joins, simulating FULL JOIN in MySQL using UNION, and building the habit of always running SELECT * before executing an UPDATE or DELETE.
4. SQL Basics Part 4: Numeric, Date, and String Transformations Plus CASE Conditionals: Reshaping columns inline with date math, string slicing, CAST(), and conditional bucketing with CASE WHEN.
5. SQL Basics Part 5: Window Functions, Running Totals, Ranking, LAG/LEAD, and PARTITION BY: The turning point where SQL started feeling like real data analysis, using OVER(), ROWS BETWEEN frames, ROW_NUMBER(), RANK(), DENSE_RANK(), PARTITION BY, and row-to-row comparisons with LAG() and LEAD().
6. SQL Basics Part 6: Subqueries and CTEs: Moving from nested inside-out subqueries to readable, top-to-bottom pipelines with WITH clauses.
7. SQL Real-World Scenarios & Reusable SQL: Views, Stored Procedures, and Functions: Applying all of those fundamentals to classic problems like finding the $N$th highest value per category, deduplicating messy tables, and saving logic with views, procedures, and custom functions.

What Writing It All Down Taught Me

There is a huge gap between watching someone write a DENSE_RANK() OVER (PARTITION BY category ORDER BY unit_price DESC) query in a video and sitting down to explain why RANK() would fail if two items tied for 4th place.

Writing these posts forced me to slow down and test edge cases myself: dropping a primary key just to see how duplicate rows behave with ROW_NUMBER(), or checking why CREATE FUNCTION fails in MySQL without DETERMINISTIC and NO SQL. Every time I got stuck trying to explain a query in plain English, it pointed straight at a gap in my own understanding.

What I’m Learning Next: Database Design & Data Modeling

Now that I’m comfortable querying data, transforming columns, and writing window functions and stored procedures, I noticed a new gap: almost every query I’ve written so far assumed the tables (dim_customer, dim_product, dim_date, orders) were already designed for me.

Writing good queries matters, but if the underlying database schema is poorly designed, no amount of clever CTEs or window functions will save you. Why were those tables named dim_customer and dim_product in the first place? When do you normalize tables to avoid redundancy, and when do you use star schemas with fact and dimension tables for analytics?

So my next learning track is Database Design & Data Modeling, starting with Ansh Lamba’s course:

• Database Design & Data Modeling Full Course For Beginners (Ansh Lamba on YouTube)

Ansh Lamba’s teaching style is a big part of why my SQL track clicked so well (if you noticed customer names like 'love', 'ansh', and 'lamba' in my Part 3 join tables, that’s where they came from!). Moving from writing SQL queries to designing schemas and data models from scratch feels like the exact right next step. As I work through it, I’ll be documenting what I learn right here on the blog.