SQLMaxx
Sign in Start free
N021-M2 Tier 2 · Core SQL · medium ecommerce · Brightlane

Return the subcategory name and parent category name for every subcategory whose parent is `'Clothing'`

Part of Self-Joins in SQL

The problem

Brightlane's content team is reviewing the Clothing section and needs a list of all subcategories within it.

Write a query to return the subcategory name and parent category name for every subcategory whose parent is 'Clothing'.

Assumptions:

  • The categories table contains every defined category in the catalogue.
  • The condition parent.name = 'Clothing' applies to the parent role of the self-pairing, not the subcategory role.

Output:

  • One row per subcategory of Clothing, with columns subcategory_name and parent_category_name.
Schema · ecommerce 5 tables
categories
id integer
name text
parent_id? integer
products
id integer
name text
category_id integer
price numeric
stock_qty integer
attributes? jsonb
order_items
id integer
order_id integer
product_id integer
quantity integer
unit_price numeric
customers
id integer
name text
email text
city? text
country text
created_at timestamptz
is_active boolean
orders
id integer
customer_id integer
ordered_at timestamptz
status text
total_amount numeric
Check answerShift Ctrl ↵

Run previews · Check grades

Write a query, then run it to see results here.
Worked solution Try it yourself first
Solution query
SELECT
  c.name AS subcategory_name,
  p.name AS parent_category_name
FROM
  categories c
  JOIN categories p ON c.parent_id = p.id
WHERE
  p.name = 'Clothing'

The shape

The filter applies to the parent role, not the subcategory role, so the WHERE predicate names the parent alias: p.name = 'Clothing'. Each row in the result is a child of the Clothing category, and which alias the filter sits on is what makes that true.

Clause by clause

  • SELECT c.name AS subcategory_name, p.name AS parent_category_name returns the child name and the parent name from the two aliased instances of categories. p.name is 'Clothing' on every row because of the filter below; c.name varies across Men's, Women's, and Kids'.
  • FROM categories c reads the table in the subcategory role.
  • JOIN categories p ON c.parent_id = p.id reads the same table again in the parent role and links each row to its parent.
  • WHERE p.name = 'Clothing' restricts the parent role to the row named 'Clothing'. The subcategory role is unfiltered, so every child of Clothing is returned.

Why this and not WHERE c.name = 'Clothing'

The alias on the filter decides which role is being constrained. p.name = 'Clothing' returns the three children of Clothing. c.name = 'Clothing' would return one row — Clothing itself paired with its own parent (which is NULL, so actually zero rows in this schema). Same column, same value, different alias, opposite question. The prompt asks for subcategories of Clothing, so the filter names the parent.

The trap

When the same column exists on both aliases (c.name and p.name are both valid here), writing the filter without thinking about role assignment is the silent failure mode. The query parses, runs, and returns a result that looks reasonable until someone notices the row count is wrong. Decide which role the prompt is constraining first, then write the filter on that alias.

You practiced filtering on the parent side of a self-join. The recurring shape: per-alias filters are independent — choosing the right alias for each filter is what scopes the result correctly.

How you actually get good at SQL

Reading explains SQL. Writing it, over and over with instant feedback, is what makes you fluent.

That's the whole SQLMaxx loop: 600+ real problems, instant AI feedback, mastery you can actually see, and spaced review that won't let you forget.

A stack of SQL practice problem cards, the top card showing an employees table.
615 problems · 66 concepts

Real problems. Not toy examples.

615 hand-built problems spanning all 66 concepts, from basic SELECTs to window functions, built on real schemas and real business questions, the kind you'll actually get asked on the job. Enough reps to make SQL automatic.

A retro computer showing a SQL query marked correct with a green checkmark.
Instant AI feedback

Write a query. Know if it's right in one second.

No copying an answer and hoping it clicked. The AI grader checks your real query against real data, catches exactly what's wrong, and explains the fix in plain English, like a senior analyst reading over your shoulder on every problem.

A circular mastery progress dial filling from blue to green, the SQLMaxx diamond at its center.
Mastery tracking

Stop guessing whether you actually know it.

SQLMaxx tracks every concept and shows you what you've mastered and what's still shaky. Your skills fill in one concept at a time, so 'I think I get joins' becomes something you can prove.

A SQL query editor circled by a blue return arrow with a clock, scheduled to come back for review.
Spaced review

Learn it once. Keep it for good.

Most of what you learn this week fades by next week. So when a concept comes due for review, SQLMaxx hands you a fresh problem to solve from a blank editor, not a flashcard to re-read. A research-backed spaced-repetition algorithm (FSRS) times each return for right before you'd forget, so your SQL is still there months later, when the interview or the job actually needs it.

Practice, feedback, mastery, review. That's the loop that turns reading into real skill.

Start free

No account, no credit card. Start solving in under a minute.