Return each customer ID that appears in the orders data, with no duplicates

The shape

DISTINCT customer_id turns the orders table — which has one row per order — into a presence-list of buyers, one row per customer who has placed at least one order. A customer with twelve orders shows up once; a customer with one shows up once; a customer with zero doesn't show up at all.

Clause by clause

• SELECT DISTINCT customer_id returns the unique customer_id values present in whatever rows FROM hands up. Every order contributes its customer_id to the candidate set, and the deduplication runs across that set to produce one row per buyer.
• FROM orders is the row source. Critically, this is the transactional table — the orders themselves — not the customers table. That asymmetry is what makes the result a presence-list rather than a customer roster.

Why this and not SELECT customer_id FROM customers

Reading from customers would give back every customer Brightlane has on file, including the ones who have never placed an order. The loyalty campaign is targeting active buyers, not signups. The presence semantics come from reading the orders table — being in the result means having a row in orders, which by definition means having placed at least one order.

This is the everyday pattern behind cohort-building and audience-derivation: read the fact table, deduplicate to the entity column, and the result is exactly the population that has the behaviour the fact table records. The same shape recovers "users who have logged a session," "products that have been reviewed," "employees who have submitted an expense report" — wherever the question is "who shows up here."