Intermediate
Database & SQL
#SQL
#query-narration
#joins
#window-functions
SQL Query Description Language
5 exercises — practise describing SQL operations in professional English: JOIN narration, window functions, aggregate queries, correlated subqueries, and JOIN type vocabulary.
0 / 25 completed
1 / 25
A developer narrates a query during a code review. Which description is the most professional and technically precise?
SELECT o.order_id, o.total
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE';Professional SQL narration — vocabulary guide:
Option B uses the precise technical vocabulary expected in code reviews and architecture documents.
Key SQL narration vocabulary:
Option B uses the precise technical vocabulary expected in code reviews and architecture documents.
| Informal phrasing | Professional phrasing |
|---|---|
| "grabs" | "retrieves" / "returns" / "projects" |
| "customer is from Germany" | "filters the result set WHERE country = 'DE'" |
| "JOIN orders to customers" | "performs an INNER JOIN between orders and customers ON the foreign key" |
| "returning order details" | "projects the order_id and total columns" |
Key SQL narration vocabulary:
- Project — select specific columns from the result set (from the SELECT clause)
- Filter — apply a WHERE predicate to reduce the number of rows
- Join condition — the ON clause that defines how rows between tables are matched
- Result set — the table of rows returned by the entire query
- Foreign key — the column in the child table referencing the parent table's primary key
2 / 25
A senior engineer explains a window function in a sprint review. Which description correctly and completely explains what this expression computes?
RANK() OVER (PARTITION BY department ORDER BY salary DESC)Window function vocabulary — RANK() vs. related functions:
Option A is correct. PARTITION BY resets the rank counter for each department; ORDER BY salary DESC makes rank 1 the highest earner; and RANK() (unlike DENSE_RANK) introduces gaps after ties.
Window function key vocabulary:
Option A is correct. PARTITION BY resets the rank counter for each department; ORDER BY salary DESC makes rank 1 the highest earner; and RANK() (unlike DENSE_RANK) introduces gaps after ties.
| Function | Tied rows behaviour | Gaps in sequence? | Example output |
|---|---|---|---|
RANK() | Same rank for ties | Yes | 1, 1, 3 |
DENSE_RANK() | Same rank for ties | No | 1, 1, 2 |
ROW_NUMBER() | Arbitrary tie-breaking | No | 1, 2, 3 |
Window function key vocabulary:
- PARTITION BY — divides the result set into independent groups for separate computation
- OVER clause — defines the window: the partition and sort order for the function
- Peer rows — rows with equal ORDER BY values that receive the same RANK
- Frame — the subset of rows within the partition considered by aggregate window functions (not applicable to RANK)
3 / 25
A developer describes an aggregation query to a non-technical product manager. Which description uses correct and complete English vocabulary?
SELECT category, COUNT(*) AS order_count, SUM(revenue) AS total_revenue
FROM orders
GROUP BY category;Aggregate vocabulary — narrating GROUP BY queries:
Option C is correct because it names all structural elements: the grouping column, the per-group scope, the aggregate functions, and the output aliases. This precision matters in async reviews where the reader cannot ask follow-up questions.
Key aggregate function vocabulary:
Option C is correct because it names all structural elements: the grouping column, the per-group scope, the aggregate functions, and the output aliases. This precision matters in async reviews where the reader cannot ask follow-up questions.
| SQL element | Professional narration phrase |
|---|---|
| GROUP BY column | "groups the result set by [col]" / "partitioned by [col]" |
| COUNT(*) | "the count of rows per group" |
| SUM(col) | "the sum of [col] for each group" |
| AS alias | "aliased as [name]" / "exposed as [name]" |
Key aggregate function vocabulary:
- Aggregate function —
COUNT,SUM,AVG,MIN,MAX— reduce many rows to one value per group - Scalar result — one value returned per group by the aggregate
- HAVING — filters on aggregate results after grouping (vs. WHERE which filters rows before aggregation)
- GROUP BY key — the column(s) that define group membership
4 / 25
An engineer writes a design document explaining this query. Which narration is technically accurate about how the subquery executes?
SELECT name, salary
FROM employees e
WHERE salary > (
SELECT AVG(salary)
FROM employees
WHERE department = e.department
);Correlated subquery vocabulary:
Option D is the only accurate description. The critical distinction is the keyword correlated — the inner SELECT references
Performance note for code reviews: Correlated subqueries on large tables can be expensive because they execute once per outer row. In a review, suggest rewriting as a window function (
Option D is the only accurate description. The critical distinction is the keyword correlated — the inner SELECT references
e.department from the outer query, so it re-executes once per outer row, not once globally. Options A, B, and C all describe different queries.| Subquery type | References outer query? | Execution frequency |
|---|---|---|
| Correlated subquery | Yes — references outer alias | Once per outer row |
| Uncorrelated (scalar) subquery | No | Once for the whole query |
| Derived table (subquery in FROM) | No | Once; result used as a table |
Performance note for code reviews: Correlated subqueries on large tables can be expensive because they execute once per outer row. In a review, suggest rewriting as a window function (
AVG(salary) OVER (PARTITION BY department)) or as a derived table with GROUP BY, which the planner can optimise more effectively.5 / 25
A developer writes in a PR: "The LEFT JOIN here ensures we include customers even if they have no orders." Which statement most precisely describes what a LEFT JOIN guarantees about its result set?
JOIN type vocabulary reference:
Option B is the correct and precise definition. A LEFT JOIN (also written LEFT OUTER JOIN) preserves every row from the left table — the table named before the JOIN keyword — regardless of whether a match exists in the right table.
Practical narration tip: Always name the driving table explicitly: "Since customers is the left table, every customer appears in the output — orders columns will be NULL for customers who have placed no orders." This removes ambiguity for readers who may not track which table appears on which side of the JOIN keyword.
Option B is the correct and precise definition. A LEFT JOIN (also written LEFT OUTER JOIN) preserves every row from the left table — the table named before the JOIN keyword — regardless of whether a match exists in the right table.
| JOIN type | Rows included | NULL behaviour for unmatched rows |
|---|---|---|
| INNER JOIN | Only matched rows from both tables | No NULLs from the join itself |
| LEFT JOIN | All rows from left table | Right-table columns → NULL for unmatched rows |
| RIGHT JOIN | All rows from right table | Left-table columns → NULL for unmatched rows |
| FULL OUTER JOIN | All rows from both tables | NULLs on either side for unmatched rows |
Practical narration tip: Always name the driving table explicitly: "Since customers is the left table, every customer appears in the output — orders columns will be NULL for customers who have placed no orders." This removes ambiguity for readers who may not track which table appears on which side of the JOIN keyword.
6 / 25
Sarah from the data team is explaining a query to her teammate, Mark, during a Slack discussion. The query aims to identify all orders placed by customers in Germany. Which of the following descriptions best reflects Sarah's intended meaning and technical accuracy?
```sql
SELECT o.order_id, o.total
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE';
```The key here is precision. Sarah's description accurately reflects the `SELECT` clause, specifying that it retrieves `order_id` and `total` from the `orders` table. The `JOIN` condition connects orders to customers based on their IDs, and the `WHERE` clause filters for customers where the `country` is 'DE'. Option A incorrectly states a broader scope than the query actually achieves; options C & D introduce irrelevant criteria (order value or currency), and option B is technically correct but lacks the crucial detail about *how* the data is selected.
7 / 25
Liam: "Hey team, I'm running this query to get all active users based on their last login. Can someone review it? It's pulling user data from the `users` table and filtering for records where `last_login` is greater than 30 days ago."Liam's description accurately reflects the core logic of the query. The key here is understanding that 'active user' isn't a single concept; it's defined by criteria like last login date. While simply checking for inactivity over 30 days is *a* way to determine activity, it doesn't encompass all possibilities of an active user – engagement metrics are often more complex. The other options misinterpret the query's purpose or suggest unnecessary details.
8 / 25
Alex: "I need to run a query that identifies all products with sales greater than the average sales for their category. I'm using a subquery to calculate that average. Can someone take a look?" Which of the following best describes Alex's intention and the core logic of his approach?
Alex is aiming for a more targeted result: products exceeding their *category's* average. The use of a subquery is crucial here – it calculates the category average independently, which is then used to filter the main query. Options A and D are incorrect because they don't relate to category-specific averages; option B is wrong because the subquery is specifically designed to provide this per-category data. A key misunderstanding might be that Alex isn't fully appreciating the role of the subquery in isolating the relevant average.
9 / 25
During a standup meeting, David explains he's running a query to determine the total revenue generated by each product category. He states: 'I'm selecting the `category` and calculating the count of orders for each one, plus summing up all the revenue from those orders. Basically, I want to see which categories are bringing in the most money.' Which of the following options best captures David's intention and the core logic of his query?
SELECT category, COUNT(*) AS order_count, SUM(revenue) AS total_revenue FROM orders GROUP BY category;David's intention is to aggregate data by category – count orders and sum revenue within each. The `GROUP BY` clause achieves this directly. Option A is incorrect because it describes a join, which isn't necessary for this aggregation task. Options B and C misinterpret the purpose of the `COUNT(*)` and `SUM(revenue)` functions; they aren't calculating averages or trends. Therefore, option 2 accurately reflects his description of the query's core logic.
10 / 25
Maria from the reporting team sends a PR description for a query designed to identify all orders placed by customers in France. She writes: 'This query joins the `orders` and `customers` tables to filter for customers located in France and then selects the order ID and total amount for those orders. It's crucial that we capture *all* French customer orders, regardless of whether they have other associated data.' Which of the following best describes Maria's intention and accurately reflects the query's core functionality?
SELECT o.order_id, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.country = 'FR';Maria's description correctly identifies that the query filters based on `c.country = 'FR'`, which means it selects *all* orders associated with customers in France. The key point is the inclusion of 'regardless of other potential data issues' – this highlights the importance of the JOIN and WHERE clause in ensuring all relevant French customer orders are captured. Options A and D misrepresent the filtering logic, while option B suggests a missing component when it's actually the core focus.
11 / 25
Sarah from the data team is explaining a query to her teammate, Mark, during a Slack discussion. The query aims to identify all orders placed by customers in Germany. Which of the following descriptions best reflects Sarah's intended meaning and technical accuracy?
```sql
SELECT o.order_id, o.total
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE';
```The key here is precision. Sarah's description accurately reflects the `SELECT` clause, specifying that it retrieves `order_id` and `total` from the `orders` table. The `JOIN` condition connects orders to customers based on their IDs, and the `WHERE` clause filters for customers where the `country` is 'DE'. Option A incorrectly states a broader scope than the query actually achieves; options C & D introduce irrelevant criteria (order value or currency), and option B is technically correct but lacks the crucial detail about *how* the data is selected.
12 / 25
Liam: "Hey team, I'm running this query to get all active users based on their last login. Can someone review it? It's pulling user data from the `users` table and filtering for records where `last_login` is greater than 30 days ago."Liam's description accurately reflects the core logic of the query. The key here is understanding that 'active user' isn't a single concept; it's defined by criteria like last login date. While simply checking for inactivity over 30 days is *a* way to determine activity, it doesn't encompass all possibilities of an active user – engagement metrics are often more complex. The other options misinterpret the query's purpose or suggest unnecessary details.
13 / 25
Alex: "I need to run a query that identifies all products with sales greater than the average sales for their category. I'm using a subquery to calculate that average. Can someone take a look?" Which of the following best describes Alex's intention and the core logic of his approach?
Alex is aiming for a more targeted result: products exceeding their *category's* average. The use of a subquery is crucial here – it calculates the category average independently, which is then used to filter the main query. Options A and D are incorrect because they don't relate to category-specific averages; option B is wrong because the subquery is specifically designed to provide this per-category data. A key misunderstanding might be that Alex isn't fully appreciating the role of the subquery in isolating the relevant average.
14 / 25
During a standup meeting, David explains he's running a query to determine the total revenue generated by each product category. He states: 'I'm selecting the `category` and calculating the count of orders for each one, plus summing up all the revenue from those orders. Basically, I want to see which categories are bringing in the most money.' Which of the following options best captures David's intention and the core logic of his query?
SELECT category, COUNT(*) AS order_count, SUM(revenue) AS total_revenue FROM orders GROUP BY category;David's intention is to aggregate data by category – count orders and sum revenue within each. The `GROUP BY` clause achieves this directly. Option A is incorrect because it describes a join, which isn't necessary for this aggregation task. Options B and C misinterpret the purpose of the `COUNT(*)` and `SUM(revenue)` functions; they aren't calculating averages or trends. Therefore, option 2 accurately reflects his description of the query's core logic.
15 / 25
Maria from the reporting team sends a PR description for a query designed to identify all orders placed by customers in France. She writes: 'This query joins the `orders` and `customers` tables to filter for customers located in France and then selects the order ID and total amount for those orders. It's crucial that we capture *all* French customer orders, regardless of whether they have other associated data.' Which of the following best describes Maria's intention and accurately reflects the query's core functionality?
SELECT o.order_id, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.country = 'FR';Maria's description correctly identifies that the query filters based on `c.country = 'FR'`, which means it selects *all* orders associated with customers in France. The key point is the inclusion of 'regardless of other potential data issues' – this highlights the importance of the JOIN and WHERE clause in ensuring all relevant French customer orders are captured. Options A and D misrepresent the filtering logic, while option B suggests a missing component when it's actually the core focus.
16 / 25
Sarah from the data team is explaining a query to her teammate, Mark, during a Slack discussion. The query aims to identify all orders placed by customers in Germany. Which of the following descriptions best reflects Sarah's intended meaning and technical accuracy?
```sql
SELECT o.order_id, o.total
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE';
```The key here is precision. Sarah's description accurately reflects the `SELECT` clause, specifying that it retrieves `order_id` and `total` from the `orders` table. The `JOIN` condition connects orders to customers based on their IDs, and the `WHERE` clause filters for customers where the `country` is 'DE'. Option A incorrectly states a broader scope than the query actually achieves; options C & D introduce irrelevant criteria (order value or currency), and option B is technically correct but lacks the crucial detail about *how* the data is selected.
17 / 25
Liam: "Hey team, I'm running this query to get all active users based on their last login. Can someone review it? It's pulling user data from the `users` table and filtering for records where `last_login` is greater than 30 days ago."Liam's description accurately reflects the core logic of the query. The key here is understanding that 'active user' isn't a single concept; it's defined by criteria like last login date. While simply checking for inactivity over 30 days is *a* way to determine activity, it doesn't encompass all possibilities of an active user – engagement metrics are often more complex. The other options misinterpret the query's purpose or suggest unnecessary details.
18 / 25
Alex: "I need to run a query that identifies all products with sales greater than the average sales for their category. I'm using a subquery to calculate that average. Can someone take a look?" Which of the following best describes Alex's intention and the core logic of his approach?
Alex is aiming for a more targeted result: products exceeding their *category's* average. The use of a subquery is crucial here – it calculates the category average independently, which is then used to filter the main query. Options A and D are incorrect because they don't relate to category-specific averages; option B is wrong because the subquery is specifically designed to provide this per-category data. A key misunderstanding might be that Alex isn't fully appreciating the role of the subquery in isolating the relevant average.
19 / 25
During a standup meeting, David explains he's running a query to determine the total revenue generated by each product category. He states: 'I'm selecting the `category` and calculating the count of orders for each one, plus summing up all the revenue from those orders. Basically, I want to see which categories are bringing in the most money.' Which of the following options best captures David's intention and the core logic of his query?
SELECT category, COUNT(*) AS order_count, SUM(revenue) AS total_revenue FROM orders GROUP BY category;David's intention is to aggregate data by category – count orders and sum revenue within each. The `GROUP BY` clause achieves this directly. Option A is incorrect because it describes a join, which isn't necessary for this aggregation task. Options B and C misinterpret the purpose of the `COUNT(*)` and `SUM(revenue)` functions; they aren't calculating averages or trends. Therefore, option 2 accurately reflects his description of the query's core logic.
20 / 25
Maria from the reporting team sends a PR description for a query designed to identify all orders placed by customers in France. She writes: 'This query joins the `orders` and `customers` tables to filter for customers located in France and then selects the order ID and total amount for those orders. It's crucial that we capture *all* French customer orders, regardless of whether they have other associated data.' Which of the following best describes Maria's intention and accurately reflects the query's core functionality?
SELECT o.order_id, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.country = 'FR';Maria's description correctly identifies that the query filters based on `c.country = 'FR'`, which means it selects *all* orders associated with customers in France. The key point is the inclusion of 'regardless of other potential data issues' – this highlights the importance of the JOIN and WHERE clause in ensuring all relevant French customer orders are captured. Options A and D misrepresent the filtering logic, while option B suggests a missing component when it's actually the core focus.
21 / 25
Sarah from the data team is explaining a query to her teammate, Mark, during a Slack discussion. The query aims to identify all orders placed by customers in Germany. Which of the following descriptions best reflects Sarah's intended meaning and technical accuracy?
```sql
SELECT o.order_id, o.total
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.country = 'DE';
```The key here is precision. Sarah's description accurately reflects the `SELECT` clause, specifying that it retrieves `order_id` and `total` from the `orders` table. The `JOIN` condition connects orders to customers based on their IDs, and the `WHERE` clause filters for customers where the `country` is 'DE'. Option A incorrectly states a broader scope than the query actually achieves; options C & D introduce irrelevant criteria (order value or currency), and option B is technically correct but lacks the crucial detail about *how* the data is selected.
22 / 25
Liam: "Hey team, I'm running this query to get all active users based on their last login. Can someone review it? It's pulling user data from the `users` table and filtering for records where `last_login` is greater than 30 days ago."Liam's description accurately reflects the core logic of the query. The key here is understanding that 'active user' isn't a single concept; it's defined by criteria like last login date. While simply checking for inactivity over 30 days is *a* way to determine activity, it doesn't encompass all possibilities of an active user – engagement metrics are often more complex. The other options misinterpret the query's purpose or suggest unnecessary details.
23 / 25
Alex: "I need to run a query that identifies all products with sales greater than the average sales for their category. I'm using a subquery to calculate that average. Can someone take a look?" Which of the following best describes Alex's intention and the core logic of his approach?
Alex is aiming for a more targeted result: products exceeding their *category's* average. The use of a subquery is crucial here – it calculates the category average independently, which is then used to filter the main query. Options A and D are incorrect because they don't relate to category-specific averages; option B is wrong because the subquery is specifically designed to provide this per-category data. A key misunderstanding might be that Alex isn't fully appreciating the role of the subquery in isolating the relevant average.
24 / 25
During a standup meeting, David explains he's running a query to determine the total revenue generated by each product category. He states: 'I'm selecting the `category` and calculating the count of orders for each one, plus summing up all the revenue from those orders. Basically, I want to see which categories are bringing in the most money.' Which of the following options best captures David's intention and the core logic of his query?
SELECT category, COUNT(*) AS order_count, SUM(revenue) AS total_revenue FROM orders GROUP BY category;David's intention is to aggregate data by category – count orders and sum revenue within each. The `GROUP BY` clause achieves this directly. Option A is incorrect because it describes a join, which isn't necessary for this aggregation task. Options B and C misinterpret the purpose of the `COUNT(*)` and `SUM(revenue)` functions; they aren't calculating averages or trends. Therefore, option 2 accurately reflects his description of the query's core logic.
25 / 25
Maria from the reporting team sends a PR description for a query designed to identify all orders placed by customers in France. She writes: 'This query joins the `orders` and `customers` tables to filter for customers located in France and then selects the order ID and total amount for those orders. It's crucial that we capture *all* French customer orders, regardless of whether they have other associated data.' Which of the following best describes Maria's intention and accurately reflects the query's core functionality?
SELECT o.order_id, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.country = 'FR';Maria's description correctly identifies that the query filters based on `c.country = 'FR'`, which means it selects *all* orders associated with customers in France. The key point is the inclusion of 'regardless of other potential data issues' – this highlights the importance of the JOIN and WHERE clause in ensuring all relevant French customer orders are captured. Options A and D misrepresent the filtering logic, while option B suggests a missing component when it's actually the core focus.
Frequently Asked Questions
What does the "SQL Query Description" exercise practise?
Practice describing SQL operations in professional English: INNER JOIN narration, window functions, GROUP BY aggregations, correlated subqueries, and JOIN type vocabulary. 5 exercises for intermediate IT professionals.
How many questions are in this exercise?
This exercise has 25 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Database & SQL category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "SQL Query Description" part of a larger series?
Yes — it's one exercise in the Database & SQL category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database & SQL category page for related exercises, or browse the main Exercises hub for other IT English topics.