Brightlane's merchandising team is building a product-category mapping tool and needs the complete grid of every product paired with every available category. The tool will use the grid to allow staff to reassign products by toggling cells.
Write a query to return the product name and category name for every possible combination.
Assumptions:
- The
productstable contains every product in the catalogue. - The
categoriestable contains every defined category. - The output should pair every product with every category, including the category each product is currently assigned to and every other one.
Output:
- One row per product-category combination, with columns
product_nameandcategory_name.
Schema · ecommerce 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
p.name AS product_name,
c.name AS category_name
FROM
products p
CROSS JOIN categories c The shape
CROSS JOIN pairs every product with every category, producing the complete grid the merchandising tool needs to render its toggle interface. Every cell has to exist before staff can switch between them.
Clause by clause
FROM products p CROSS JOIN categories cis the operation. NoONclause. Every row inproductspairs with every row incategories. A 25-product catalog and 6 categories produces 150 rows — one for every cell in the toggle grid.p.name AS product_namereads from the products side of each paired row. Both source tables have anamecolumn, so the table aliaspis what tells PostgreSQL which one to read.c.name AS category_namedoes the same on the categories side, pulling the category label.
Why this and not INNER JOIN ON p.category_id = c.id
An INNER JOIN on the assignment column would return only the rows where each product is paired with its current category — one row per product, the existing mapping. The toggle UI needs every cell of the grid to be reachable, including reassignments that haven't happened yet. CROSS JOIN produces that full grid by leaving the relationship out of the join entirely.
You practiced CROSS JOIN for a UI-scaffolding use case. The complete grid is what a multi-select interface or pivot-style report needs as a starting point — the actual relationships are layered on top later, often via a LEFT JOIN against the relationship table.