HardSQL challenge #266WINDOW FUNCTIONPARTITIONPERCENTAGE

Calculate Each Customer's Cumulative Share of Their Own Spend

Return each order with the percentage of that user's total spend reached so far.

The challenge runs on the SQLabHub practice database (SQLite) and uses the orders table. You can solve it in the browser, with nothing to install.

Solve This SQL Challenge

The task

Find cumulative percentage of spend per user.

A correct answer returns 200 rows with 3 columns: user_id, total, pct.

Tables used in this challenge

`orders` 200 rows

id INTEGER (PK) · user_id INTEGER · total REAL · discount REAL · item_count INTEGER · status TEXT · order_date TEXT · shipped_date TEXT · shipping_city TEXT · shipping_country TEXT

First 3 rows of the orders table
id	user_id	total	discount	item_count	status	order_date	shipped_date	shipping_city	shipping_country
1	43	2638.11	0.25	3	cancelled	2024-04-24	NULL	Los Angeles	USA
2	8	2947	0.19	5	delivered	2024-03-15	2023-04-09	Chicago	USA
3	136	683.24	0.08	2	delivered	2023-02-15	2023-07-10	Los Angeles	USA

The first rows of each table are shown. See how all the tables relate on the database schema page.

Expected output

Expected output of the challenge
user_id	total	pct
1	4064.75	100
2	1618.29	100
4	2501.23	51.43082152205606
4	843.7	68.77915978689323
4	1518.36	100

First 5 of 200 rows. This is the output of the model solution on the practice database. The task does not fix a sort order, so your rows may come back in a different order.

What you practise

Accumulating a value row by row with an ordered window
Attaching a total or average to every row with an aggregate OVER ()
Restarting a window calculation for each group with PARTITION BY
Deriving a new column from an expression and naming it with an alias

Hint and approach

Try the challenge first. Open these only when you need them.

Show the hint

SUM OVER partition

Show the step-by-step approach

How the model solution is built, in the order the database evaluates it:

Read from the orders table.
Compute SUM(total) as a running window function: it covers the rows from the start up to the current one, ordered by order_date, restarting for each user_id.
Compute SUM(total) as a window function over each user_id, so the group's value is repeated on every one of its rows.
Combine those values into pct: SUM(total) OVER (PARTITION BY user_id ORDER BY order_date) * 100.0 / SUM(total) OVER (PARTITION BY user_id).

Model solution

Checking your session…

What to watch for

Both windows use the same partition. The one with ORDER BY accumulates, and the one without is the user's full total, so each customer's final order reaches 100.

Running totals. With ORDER BY and no frame, rows that tie on the sort column are added together in one step. Use ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW for a strict row-by-row total.
Window aggregates. A window aggregate keeps every row, while a plain aggregate collapses them. Mixing the two in one SELECT without GROUP BY is an error.
PARTITION BY. PARTITION BY is not GROUP BY: it keeps every row and only decides which rows a window function looks at.

Solve This SQL Challenge