in my work, I’ve written numerous SQL queries to extract insights from knowledge. It’s at all times a difficult activity as a result of it’s not solely essential to write down environment friendly queries, but in addition easy sufficient to take care of over time.
With every new downside comes a brand new lesson, and lately, I’ve been diving into SQL window features. These highly effective instruments are extremely helpful when that you must carry out calculations throughout a set of rows with out dropping the granularity of particular person data.
On this article, I’ll break down SQL window features step-by-step. They may appear advanced or unintuitive at first, however when you perceive how they work, you’ll see how indispensable they are often. Are you prepared? Let’s dive in and grasp them collectively!
Desk of contents
- Why do we’d like Window Capabilities?
- Syntax of Window Operate
- 4 Easy Examples
Why do we’d like Window Capabilities?
To know the facility of Window Capabilities, let’s begin with a easy instance. Think about we’ve a desk containing six orders from an e-commerce web site. Every row contains the order id, the date, the product, its model and worth.

Let’s suppose that we wish to calculate the overall worth for every model. Utilizing the GROUP BY clause, we will write a question like this:
SELECT
model,
SUM(worth) as total_price
FROM Orders
GROUP BY model
This returns a consequence the place every row represents one model, together with the overall worth of all orders below that model.
|model |total_price|
|-------|-----------|
|carpisa|30 |
|nike |175 |
|parfois|25 |
|zara |65 |
This aggregation removes the main points of particular person orders, because the output solely contains one row for model. What if we wish to preserve all the unique rows and add the overall worth for every model as an additional area?
Through the use of SUM(worth) OVER (PARTITION BY model)
, we will calculate the overall worth for every model with out collapsing the rows:
SELECT
order_id,
date,
product,
model,
worth,
SUM(worth) OVER (PARTITION BY model) as total_price
FROM Orders
We have now obtained a consequence like this:
|order_id|date |product|model |worth|total_price|
|--------|----------|-------|-------|-----|-----------|
|6 |2025/05/01|bag |carpisa|30 |30 |
|1 |2024/02/01|footwear |nike |90 |175 |
|3 |2024/06/01|footwear |nike |85 |175 |
|5 |2025/04/01|bag |parfois|25 |25 |
|2 |2024/05/01|costume |zara |50 |65 |
|4 |2025/01/01|t-shirt|zara |15 |65 |
This question returns all six rows, preserving each particular person order, and provides a brand new column exhibiting the overall worth per model. For instance, the order with model Carpisa reveals a complete of 30, because it’s the one Carpisa order, the 2 orders from Nike present 175 (90+85), and so forth.
It’s possible you’ll discover that the desk is not ordered by order_id. That’s as a result of the window operate partitions by model, and SQL doesn’t assure row order until explicitly specified. To revive the unique order, we have to merely add an ORDER BY
clause:
SELECT
order_id,
date,
product,
model,
worth,
SUM(worth) OVER (PARTITION BY model) as total_price
FROM Orders
ORDER BY order_id
Lastly, we’ve the output containing all of the required particulars:
|order_id|date |product|model |worth|total_price|
|--------|----------|-------|-------|-----|-----------|
|1 |2024/02/01|footwear |nike |90 |175 |
|2 |2024/05/01|costume |zara |50 |65 |
|3 |2024/06/01|footwear |nike |85 |175 |
|4 |2025/01/01|t-shirt|zara |15 |65 |
|5 |2025/04/01|bag |parfois|25 |25 |
|6 |2025/05/01|bag |carpisa|30 |30 |
Now, we’ve added the identical aggregation as GROUP BY
, whereas preserving all the person order particulars.
Syntax of Window Capabilities
Basically, the window operate has a syntax that appears like this:
f(col2) OVER(
[PARTITION BY col1]
[ORDER BY col3]
)
Let’s break it down. f(col2)
is the operation you wish to carry out, similar to sum, depend and rating. OVER
clause defines the “window” or the subset of rows over which the window operate operates. PARTITION BY col1
divides the information into teams and ORDER BY col1
determines the order of rows inside every partition.
Furthermore, window features fall into three major classes:
- mixture operate:
COUNT
,SUM
,AVG
,MIN
andMAX
- rank operate:
ROW_NUMBER
,RANK
,DENSE_RANK
,CUME_DIST
,PERCENT_RANK
andNTILE
- worth operate:
LEAD
,LAG
,FIRST_VALUE
andLAST_VALUE
4 Easy Examples
Let’s present totally different examples to grasp window features.
Instance 1: Easy Window Operate
To know the idea of window features, let’s begin with an easy instance. Suppose we wish to calculate the overall worth of all of the orders within the desk. Utilizing a GROUP BY
clause would give us a single worth: 295
. Nonetheless, that may collapse the rows and lose the person order particulars. As an alternative, if we wish to show the overall worth alongside every report, we will use a window operate like this:
SELECT
order_id,
date,
product,
model,
worth,
SUM(worth) OVER () as tot_price
FROM Orders
That is the output:
|order_id|date |product|model |worth|tot_price|
|--------|----------|-------|-------|-----|---------|
|1 |2024-02-01|footwear |nike |90 |295 |
|2 |2024-05-01|costume |zara |50 |295 |
|3 |2024-06-01|footwear |nike |85 |295 |
|4 |2025-01-01|t-shirt|zara |15 |295 |
|5 |2025-04-01|bag |parfois|25 |295 |
|6 |2025-05-01|bag |carpisa|30 |295 |
On this manner, we obtained the sum of all costs over your entire dataset and repeated it for every row.
Instance 2: Partition by clause
Let’s now calculate the common worth per yr whereas nonetheless preserving all the main points. We are able to do that by utilizing the PARTITION BY
clause inside a window operate to group rows by yr and compute the common inside every group:
SELECT
order_id,
date,
product,
model,
worth,
spherical(AVG(worth) OVER (PARTITION BY YEAR(date) as avg_price
FROM Orders
Right here’s what the output seems to be like:
|order_id|date |product|model |worth|avg_price|
|--------|----------|-------|-------|-----|---------|
|1 |2024-02-01|footwear |nike |90 |75 |
|2 |2024-05-01|costume |zara |50 |75 |
|3 |2024-06-01|footwear |nike |85 |75 |
|4 |2025-01-01|t-shirt|zara |15 |23.33 |
|5 |2025-04-01|bag |parfois|25 |23.33 |
|6 |2025-05-01|bag |carpisa|30 |23.33 |
That’s nice! We see the common worth for every year alongside every row.
Instance 3: Order by clause
Probably the greatest methods to know how ordering works inside window features is to use a rating operate. Let’s say we wish to rank all orders from highest to lowest worth. Right here’s how we will do it utilizing the RANK()
operate:
SELECT
order_id,
date,
product,
model,
worth,
RANK() OVER (ORDER BY worth DESC) as Rank
FROM Orders
We acquire an output like this:
|order_id|date |product|model |worth|Rank|
|--------|----------|-------|-------|-----|----|
|1 |2024-02-01|footwear |nike |90 |1 |
|3 |2024-06-01|footwear |nike |85 |2 |
|2 |2024-05-01|costume |zara |50 |3 |
|6 |2025-05-01|bag |carpisa|30 |4 |
|5 |2025-04-01|bag |parfois|25 |5 |
|4 |2025-01-01|t-shirt|zara |15 |6 |
As proven, the order with the best worth will get rank 1, and the remaining comply with in descending order.
Instance 4: Mix Partition by and Group by clauses
Within the earlier instance, we ranked all orders from the best to the bottom worth throughout your entire dataset. However what if we wish to restart the rating for every year? We are able to do that by including the PARTITION BY
clause within the window operate. This permits for splitting the information into separate teams by yr and sorting the orders from the best to the bottom worth.
SELECT
order_id,
date,
product,
model,
worth,
RANK() OVER (PARTITION BY YEAR(date) ORDER BY worth DESC) as Rank
FROM Orders
The consequence ought to appear like this:
|order_id|date |product|model |worth|Rank|
|--------|----------|-------|-------|-----|----|
|1 |2024-02-01|footwear |nike |90 |1 |
|3 |2024-06-01|footwear |nike |85 |2 |
|2 |2024-05-01|costume |zara |50 |3 |
|6 |2025-05-01|bag |carpisa|30 |1 |
|5 |2025-04-01|bag |parfois|25 |2 |
|4 |2025-01-01|t-shirt|zara |15 |3 |
Now, the rating restarts for every year, as we determined.
Ultimate ideas:
I hope this information helped you get a transparent and sensible introduction to SQL window features. At first, they could really feel a bit unintuitive, however when you examine them aspect by aspect with the GROUP BY
clause, the worth they convey turns into a lot simpler to know.
From my very own expertise, window features have been extremely highly effective for extracting insights with out dropping row-level element, one thing that conventional aggregations cover. They’re extremely helpful when extracting metrics like totals, rankings, year-over-year or month-over-month comparisons.
Nonetheless, there are some limitations. Window features will be computationally costly, particularly over giant datasets or advanced partitions. It’s essential to judge whether or not the added flexibility justifies the efficiency tradeoff in your particular use case.
Thanks for studying! Have a pleasant day!
Helpful assets: