SQL-PROJECT: A Portfolio Repo That Turns Messy Netflix Data Into an SQL Interview Drill

Most SQL portfolios try to impress with breadth. This one is sharper than that. It builds a small, controlled world where the inputs are messy enough to feel real and the outputs are predictable enough to teach something useful.

That is the repo’s trick. It is not a reusable product, and it does not pretend to be one. It is a practice range for analyst work, built around the kinds of problems hiring teams actually ask about: bad strings, awkward dates, denormalized fields, and queries that still need to answer a business question.

The clever part is not the queries. It is the dataset

The repo frames itself as a MySQL project, but the real design choice comes earlier. The data is synthetic, realistic, and intentionally answerable. That means the author can stage edge cases on purpose instead of hoping a public dataset happens to contain them.

That matters because SQL practice often fails in one of two ways. Either the data is too clean and the exercise feels fake, or the data is so large and unruly that the lesson gets buried. Here, the dataset sits in the middle: compact enough to inspect, messy enough to matter.

A one-table schema built for analysis, not elegance

The repository uses a single flat table, `netflix`, inside a MySQL database. From a relational design perspective, that is not elegant. From a portfolio perspective, it is smart. One table keeps the project legible and lets the reader focus on the queries instead of on joins and schema choreography.

CREATE TABLE netflix (
  show_id INT,
  type TEXT,
  title TEXT,
  director TEXT,
  cast TEXT,
  country TEXT,
  date_added TEXT,
  release_year INT,
  rating TEXT,
  duration TEXT,
  listed_in TEXT,
  description TEXT
);

That structure reveals the project’s priorities. It is optimized for analytical retrieval, not transaction safety. In production, fields like cast and listed_in would usually be normalized. Here, they are left as strings because the repo wants to demonstrate the pain of working with text-heavy data in the wild.

How the repo teaches analyst-grade SQL

The query progression reads like a short curriculum. It starts with counting and ranking, then moves into parsing dates, then into string extraction, then into classification. That sequence mirrors how analysts actually work when they inherit a table that was designed for convenience, not rigor.

The strongest signal is the use of window functions. `RANK()` is not there for decoration. It turns a simple aggregation into a comparison across partitions, which is exactly the kind of move that separates SQL memorization from SQL fluency.

SELECT type, rating, COUNT(*) AS total,
       RANK() OVER (PARTITION BY type ORDER BY COUNT(*) DESC) AS rnk
FROM netflix
GROUP BY type, rating;

The same pattern shows up in the cleanup work. `STR_TO_DATE` converts a string into something MySQL can sort and compare. `SUBSTRING_INDEX` peels the number off a duration like `6 Seasons`. `LIKE` scans text fields where a proper junction table would have been better, but no such table exists. In other words: the repository teaches the analyst’s reality, not the database purist’s ideal.

Why messy strings are the whole point

The project leans into a reality that many beginner tutorials skip: analysts often inherit ugly tables. Comma-separated names, dates stored as text, descriptions full of keywords, and categorical fields embedded in freeform strings are not edge cases. They are the job.

That is why the repo’s use of `LIKE` and string splitting is more than a technique demo. It is an argument about what SQL is for. In a perfect schema, you would join clean dimensions and call it a day. In a real business setting, you often do not get that luxury, and the value comes from producing a useful answer anyway.

The business question hiding inside the syntax

The payoff is the classification query. A rule like `CASE WHEN description LIKE '%kill%' OR description LIKE '%violence%' THEN 'Bad' ELSE 'Good' END` looks technical on the surface, but it is really a decision rule. It turns free text into a business-facing label.

SELECT title,
       CASE
         WHEN description LIKE '%kill%' OR description LIKE '%violence%'
         THEN 'Bad'
         ELSE 'Good'
       END AS content_class
FROM netflix;

That is the bridge this repo builds so well. The syntax is straightforward, but the intent is strategic. Once a description can be classified, it can be counted, filtered, reviewed, or escalated. This is where SQL stops feeling like a school exercise and starts feeling like decision support.

What this repo says about portfolio strategy

This project is a hiring artifact disguised as a SQL notebook. It does not need scale to be useful. It needs structure, progression, and a clear point of view. Those are the things recruiters and hiring managers can actually read in a few minutes.

That is why the repo works. It shows that the author knows how to turn raw inputs into named questions, then into answerable queries, then into business language. That is a better signal than a random grab bag of advanced syntax.

In that sense, the repository is intentionally modest. It is not trying to be the best database design on GitHub. It is trying to show that the author can survive the shape of real analyst work. For a portfolio, that is the stronger claim.