SQL for Non-Developers: The 6 Queries That Answer 90% of Business Questions

GROUP BY: one row per category

SELECT product_category,
       COUNT(*) AS orders_placed,
       SUM(order_total) AS total_spend
FROM orders
GROUP BY product_category
ORDER BY total_spend DESC;

This is where SQL starts doing what you'd otherwise build a pivot table for. GROUP BY collapses rows into one line per category, and the functions in the SELECT, here COUNT and SUM, summarise each group. (AS just names the new columns.)

Look at what the five rows actually say: furniture is BrightOffice's rarest order type, 46 orders out of 460, and its biggest earner at £34,893.64. Paper and envelopes were ordered three times as often and brought in barely a quarter as much. One six-line query, and you know which category deserves the sales push. That sentence is what GROUP BY exists to produce.

The gotcha that trips everyone up first: every column in the SELECT that isn't being summarised must also appear in the GROUP BY. Here product_category is in both; that's the rule being followed, not a coincidence. The database can't put 460 different order dates on five summary rows, so it refuses to guess.

JOIN: pull data from more than one table

Business data almost never lives in one table. BrightOffice's orders table doesn't store company names; it stores a customer_id like 101, and the name lives once in customers. That's deliberate good design, and JOIN is how you stitch the two back together when a human needs to read the result:

SELECT customers.company_name, orders.order_date, orders.order_total
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id;

The ON clause is the matching rule: rows pair up where the customer_id values agree. The grid now shows a company name against every order, and it still shows exactly 460 rows, one per order. That unchanged count is worth noticing; a join that suddenly returns far more rows than you started with is a warning sign we'll come back to in the gotchas.

COUNT, SUM, AVG: the numbers behind the question

You've met COUNT and SUM inside the GROUP BY, but they work on their own too. With no grouping, the whole result collapses to a single row of headline numbers:

SELECT COUNT(*) AS orders_placed,
       SUM(order_total) AS revenue,
       CAST(AVG(order_total) AS decimal(10, 2)) AS average_order
FROM orders
WHERE order_date >= '2026-01-01';

BrightOffice's year to date, straight off the grid: 184 orders, £30,009.70 of revenue, £163.10 average order. The three functions read exactly as they sound. COUNT(*) counts rows, SUM totals a numeric column, and AVG averages it (the CAST just trims the average to two decimal places for display).

Put together with the other five patterns, that's most of what "can you pull me a number on X" turns out to mean.

Putting all six together

Here's a question a sales manager would actually ask: "Which customers have spent over £2,000 with us this year, and how many orders did that take?" Every pattern from this guide, one query:

SELECT customers.company_name,
       COUNT(*) AS orders_placed,
       SUM(orders.order_total) AS total_spend
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.order_date >= '2026-01-01'
GROUP BY customers.company_name
HAVING SUM(orders.order_total) > 2000
ORDER BY total_spend DESC;

Read it top to bottom: join orders to customer names, keep this year's orders, collapse to one row per customer, keep only the customers whose total clears £2,000, biggest first. The answer is six firms, led by Kingfisher Travel with 13 orders and £3,078.37.

The one new word is HAVING: it filters groups after they've been summarised, which WHERE can't do because WHERE runs before the grouping exists. Rule of thumb: conditions on raw rows go in WHERE, conditions on totals go in HAVING.

Common gotchas (and the fixes)

“Column ... is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.” SQL Server's wording of the most common first error. Every plain column in your SELECT needs to be in the GROUP BY too; only summarised columns (inside COUNT, SUM, AVG) are exempt. Fix: add the column to GROUP BY, or wrap it in an aggregate.

A JOIN returns far more rows than expected. The matching rule is pairing more rows than you intended, usually because the ON column isn't unique on one side. Healthy sign: our join returned exactly the 460 orders we started with. If 460 becomes 4,600, fix the join before you trust anything downstream.

A date filter behaves oddly. Write dates as 'YYYY-MM-DD' and prefer >= and < boundaries over BETWEEN. If the column stores a time as well as a date, <= '2026-08-31' silently cuts off everything after midnight on the 31st; use < '2026-09-01' instead.

The total looks plausible but is wrong. Almost always a JOIN duplicating rows before a SUM, so each duplicated row is counted twice. Check the un-summarised row count first (gotcha two), then sum. A number that's exactly 2x or 3x what you expected is this bug's signature.

You can answer your own questions now

Six patterns (SELECT, WHERE, ORDER BY, GROUP BY, JOIN and the COUNT/SUM/AVG family) took a 460-row orders table from "ask IT" to "which six customers cleared £2,000 this year, sorted". The same six will do it on your sales table, your ticket queue, your sign-up log.

If you'd rather build this skill hands-on, on realistic business scenarios with a trainer in the room to answer the "why did that error happen?" questions the moment they happen, that's exactly what our instructor-led SQL courses are for.