Brightlane's CRM team is migrating to a new email platform and needs a full contact export to seed the new system.
Write a query to return the name and email of every customer.
Assumptions:
- The
customerstable contains every customer Brightlane has on file. - Each customer has a
nameand anemailrecorded.
Output:
- One row per customer, with columns
nameandemail.
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
name,
email
FROM
customers The shape
FROM customers is the row source, and naming name and email in the SELECT list trims every row down to the two fields the email platform needs to seed a contact.
Clause by clause
SELECT name, emailkeeps only the two columns the migration cares about. Thecustomerstable likely holds plenty of other fields — created-at timestamps, addresses, whatever else Brightlane records — and none of them need to go to the new platform. Naming the two relevant columns is how the query filters horizontally: the rows stay, the irrelevant columns drop.FROM customersreads every customer row Brightlane has on file. With noWHEREclause, the full population comes through — active customers, inactive ones, recent signups, everyone. That's the right shape for a contact export seeding a new system from scratch.
Why this and not SELECT *
SELECT * feels like "give me everything," but the new email platform doesn't need everything. It needs names and emails. Naming the two columns the consumer needs keeps the export tight and the contract explicit: this query produces a two-column file, today and next quarter, regardless of what columns get added to customers later.
You practiced selecting only the columns you need from a table rather than returning every column. Picking columns explicitly is what keeps query results focused and stable as the underlying schema changes.