Brightlane's operations director reviews a daily order pipeline report at the start of each morning to spot fulfillment bottlenecks.
Write a query to return every order's ID, the ID of the customer who placed it, the timestamp it was placed, and its current status.
Output:
- One row per order, with columns
id,customer_id,ordered_at, andstatus.
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
id,
customer_id,
ordered_at,
status
FROM
orders The shape
FROM orders reads the full pipeline of orders, and the four columns in the SELECT list give the operations director everything they need for the morning bottleneck scan: which order, whose order, when it was placed, and where it stands.
Clause by clause
SELECT id, customer_id, ordered_at, statusreturns four columns per row in that order. Order is doing pedagogical work here — the result reads in a useful sequence for the director: the identifier first, then who placed it, then when, then what state it's in. PostgreSQL preserves theSELECT-list order in the result set, so the way the columns are written is the way they land on screen.FROM ordersis the row source: the table holding every order in the pipeline. One row per order comes back, which is what makes this an order-level report rather than a line-item report. The same business question can be asked at different grains depending on which table sits in theFROMclause; this one is the order grain.
Why this and not SELECT *
The orders table almost certainly carries more columns than these four — totals, shipping addresses, payment references. A bottleneck scan doesn't need any of that. Returning the four columns the director uses keeps the report scannable and the load on the database small, which matters when this query runs every morning across the full pipeline.
Naming columns also documents intent. Someone reading the query later can see immediately what the morning report needs; with SELECT * they'd have to inspect the orders schema to figure out what the result actually contains. Explicit column lists are how a query stays readable across the lifetime of the report.
You practiced returning multiple columns from one table by listing them in the SELECT clause. Multi-column reads are the everyday shape of any query that needs more than one piece of information about each row.