SQL: Asking Clear Questions of Your Data

SQL is a language used to work with data in many databases. For a business leader, the first useful skill is explaining a question precisely enough that someone can check the answer.

An AI can write a plausible query while answering the wrong business question. “How much business have we got?” leaves a great deal to guess. “Show the open orders for the North region, in GBP, using this four-row practice table” gives us something we can inspect.

Read a small query in English

These are invented order amounts, not a report from a real company:

Suppose the table is called orders and its fields are order_id, region, status and amount_gbp:

SELECT order_id, amount_gbp
FROM orders
WHERE region = 'North' AND status = 'Open'
ORDER BY order_id;

SELECT says which fields to return. FROM names the table. WHERE restricts the rows. ORDER BY gives the requested order. PostgreSQL's query tutorial explains these building blocks.

The answer is O101, GBP120; O103, GBP45. O104 is in the North, but it is cancelled. It must not slip into the open-order answer.

Ask for a total without changing the question

SELECT COUNT(*) AS order_count, SUM(amount_gbp) AS total_gbp
FROM orders
WHERE region = 'North' AND status = 'Open';

For this exact sample, the result is two orders, GBP165. COUNT(*) counts the selected rows; SUM adds their amounts. The SQLite aggregate reference explains these operations, including how missing values can affect a total. SQL dialects differ; a query intended for your real system needs checking against that system.

Do the small example by hand before asking the AI. If it gives GBP200, find the extra GBP35 rather than accepting a confident explanation. If an amount is missing, ask how that is handled; an unknown amount is not evidence of zero.

The business questions still come first

Before trusting a larger answer, I would ask:

• What does one row represent, and which rows qualify?
• Which period and date field apply? Are amounts in one currency and on the same tax basis?
• If tables are joined, could one order appear several times?
• How are missing values, duplicates and cancellations handled?
• Can we check a few original records against the result?

Joins combine information from tables. PostgreSQL's join tutorial shows why the matching condition matters. Joining one order to several related rows can repeat it; adding the repeated order amount can inflate a total. A technically valid query is not proof of a valid business measure.

Keep learning separate from production access

The example queries above only retrieve the displayed sample. SQL also has commands that change or remove information. Even reading can expose confidential data or put load on a system. Ask the technical owner to provide an approved practice environment, limited access and suitable query limits before any real execution.

In applications, developers should keep user-supplied values separate from query instructions through parameterised queries. OWASP's SQL injection guidance explains that protection. It is not a substitute for access controls or checking the intended calculation.

Ask your AI to teach you

The prompt does not enforce database permissions. Use a disconnected learning chat for this exercise, not an agent attached to production.

Check that you can use it

Explain why counting customers, counting orders and adding order values are different questions. Then explain why GBP200 is wrong for our open North orders. You have learned something more useful than memorising punctuation.

Revisit databases if rows and keys are unfamiliar. Continue to file types for the exported copies these queries often produce.

Sources and boundaries

Sources linked above were checked on 21 October 2026. The four-row example is original teaching material. Its arithmetic and SQL can be checked independently in a disposable local database. No production query, measured AI performance, or approval to run queries against a company system is implied.