How do you recognize a good SQL corrected exercise?
A good exercise doesn't just require writing syntax. It presents a business question, describes the available tables and specifies the expected result. The correction then explains the reasoning, controls and possible alternatives.
The validator must compare the result obtained, not just the query text. Two different solutions can be correct if they return the right columns, rows, and exact calculations.
- Context that explains why the answer is useful.
- Data rich enough to reveal logic errors.
- Progressive cues that help without immediately delivering the solution.
- A commented correction and control of the result.
The five-step method
Before launching the editor, write in a few words the scope and the expected granularity. Then build the query by blocks: source, filters, calculations, grouping and sorting. Run after each step to isolate errors.
If you're stuck, ask for a concept clue first. View the solution only after a real attempt, then close it and rewrite the query without looking at it.
- 1. Reformulate the business question.
- 2. Identify the necessary tables, keys and columns.
- 3. Predict the shape of the result.
- 4. Write and execute the query in stages.
- 5. Compare, correct, then explain the solution in your words.
Beginner level: filter without losing business sense
Question: Show paid orders over €100, from newest to oldest. The orders table contains order_id, ordered_at, status, and amount.
Start by selecting only the useful columns. Then add both conditions in WHERE, then sort. The correction below uses a strict operator: an order of exactly €100 is not included.
SELECT order_id, ordered_at, amount
FROM orders
WHERE status = 'paid'
AND amount > 100
ORDER BY ordered_at DESC;Intermediate level: aggregate after a join
Question: Find the five customers who generated the most paid revenue. The names are in customers and the amounts are in orders.
The join links orders to their customer. WHERE excludes unpaid orders before aggregation. GROUP BY produces one row per customer, then LIMIT keeps the top five after sorting.
- Also grouping by customer_id distinguishes two people with the same name.
- The status filter is applied before SUM.
- A join to the command lines would require additional duplicate checking.
SELECT
c.customer_id,
c.full_name,
SUM(o.amount) AS revenue
FROM customers AS c
INNER JOIN orders AS o
ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id, c.full_name
ORDER BY revenue DESC
LIMIT 5;Advanced level: classify without removing detail
Question: Rank each paid order in its city, from highest to lowest. Unlike GROUP BY, a window function keeps each command in the result.
DENSE_RANK assigns the same rank to identical amounts and does not create a hole after a tie. PARTITION BY city starts the ranking again for each city.
SELECT
order_id,
city,
amount,
DENSE_RANK() OVER (
PARTITION BY city
ORDER BY amount DESC
) AS city_rank
FROM orders
WHERE status = 'paid'
ORDER BY city, city_rank, order_id;How to use correction without losing learning
A correction is useful when it explains why each clause exists and how to control the result. It becomes counterproductive if it is copied before any attempt or if it imposes only one form of query.
After understanding a solution, modify a constraint: change the threshold, keep customers without orders, or calculate a different ranking. This variation verifies that the reasoning is transferable.
- Clue 1: Identify the missing concept.
- Hint 2: propose the structure of the clause.
- Explanation: relate the clause to the business need.
- Solution: Show a verified query and its limits.
Build a progression from beginner to advanced
The difficulty should not come from an ambiguous statement. It increases when the exercise combines more decisions: choosing the right granularity, linking several tables, managing NULL values, comparing periods or using a window function.
A coherent progression regularly returns to previous notions in new contexts. It avoids ten almost identical exercises where only the table name or the filter value changes.
- Beginner: reading, filters, sorting and simple calculations.
- Intermediate: aggregations, joins, CASE and subqueries.
- Advanced: CTE, window functions, data quality and optimization.
- Project: transform a business request into a controlled analysis.
Diagnose errors rather than starting again randomly
A syntax error prevents execution; a logic error returns a false result. Start by reading the reported line, then reduce the query to the smallest block that works. For a result error, check the number of records returned at each join and the scope of the filters.
Keep a few control queries: number of orders, total sum, distinct status values and unmatched lines. They allow you to quickly verify a more complex analysis.
Choose your next exercise
The SQL.tn catalog allows you to filter exercises by level and concept. If you don't know where to start, the placement test recommends a starting point. The Data Analyst course then organizes the practice around indicators and business questions.