Brightlane's data governance team is auditing for orphaned orders — orders not linked to any customer account — to flag them for remediation.
Write a query to return the ID of every such order.
Assumptions:
- The
orderstable contains every order Brightlane has processed. - The
customer_idcolumn normally links each order to the customer who placed it. - An orphaned order has
customer_idset toNULL. Brightlane's referential integrity is currently strong, so it's possible no orders meet this condition; the query should return zero rows in that case.
Output:
- One row per orphaned order, with the column
id. The result set may be empty.
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
FROM
orders
WHERE
customer_id IS NULL The shape
An audit query can legitimately return zero rows. That's the point of running it. The data governance team is asking "are there any orphaned orders?" and the answer Brightlane wants is no. The query asks the question correctly; the empty result set is the answer.
Clause by clause
SELECT idreturns just the order identifier. The governance team only needs to know which orders are orphaned; if any come back, the next step is a remediation lookup that pulls the rest. The minimal projection keeps the audit output focused.FROM ordersreads every order Brightlane has processed. The audit needs the full table; sampling would defeat the purpose.WHERE customer_id IS NULLkeeps only rows whose customer link is absent.IS NULLreturnstruefor orphans andfalsefor every order linked to a customer. Brightlane's referential integrity is currently strong, so this set happens to be empty today. Returning the IDs directly — rather than just signalling whether any exist — is what makes the result double as both a sanity check (zero rows = healthy) and a worklist (one or more rows = the IDs to remediate).
The trap
The trap on a zero-row result is reading it as a query bug instead of a real answer. "The query returned nothing — it must be broken." It isn't. The query asked a precise question and the answer is precisely none.
The failure mode worth guarding against is the opposite: a query that should find orphans but uses customer_id = NULL instead of IS NULL. That query also returns zero rows, but for the wrong reason — = against NULL evaluates to unknown, so the filter passes nothing whether orphans exist or not. The audit then reports "no orphans found" while orphans pile up unflagged. The way to tell the two cases apart is to read the operator: IS NULL is the correct test; = NULL is the bug that hides the answer.
You practiced a query that may legitimately return zero rows. An empty result set is a real answer — the absence of data is the data, in audit and quality-check workflows.