Turn a Plain-English Question Into a SQL Query

Most SQL mistakes do not come from bad syntax; they come from quietly misreading the question. An analyst hears "top customers last month" and has to decide: top by revenue or order count, which month, which time zone, do refunds count, are inactive accounts included. This prompt forces the model to slow down and surface those decisions instead of guessing. By pasting your real schema, you keep the model from inventing column names, the single most common failure when you let an LLM write SQL blind. The instruction to qualify columns, alias tables, and comment non-obvious clauses produces queries a teammate can actually review, not a one-line blob nobody trusts. Use it when you know exactly what you want in English but do not want to hand-write joins, or when you are learning a new schema and need a reviewable starting point. Always run the result against your database and sanity-check row counts before shipping a number to anyone.

What you can expect back

Assumption: revenue = SUM(total_cents)/100, refunded orders are status = 'refunded', dates compared in UTC.

```sql
SELECT c.country,
       SUM(o.total_cents) / 100.0 AS revenue
FROM orders o
JOIN customers c ON c.id = o.customer_id
-- May 2026 window, half-open to avoid edge timestamps
WHERE o.created_at >= '2026-05-01' AND o.created_at < '2026-06-01'
  AND o.status <> 'refunded'
GROUP BY c.country
ORDER BY revenue DESC
LIMIT 10;
```

Confirm: (1) created_at is stored in UTC, not local time. (2) 'refunded' is the only excluded status; partial refunds may need separate handling. (3) Customers with NULL country are dropped by the JOIN-then-GROUP; decide if you want an 'Unknown' bucket.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Paste types alongside columns; the model picks better date functions when it knows created_at is a timestamp versus a date.
• 02If the first query looks wrong, reply with the actual error or a sample of returned rows rather than re-asking from scratch.
• 03Ask for an EXPLAIN-friendly version or an index suggestion when the table is large and the query feels slow.
• 04Keep the 'confirm these assumptions' block; it is where silent business-logic bugs get caught.

Adapt it for your case