Find Customers Whose Every Order Is Larger Than the Last
Return the users with at least two orders whose order total went up every time.
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.
The task
Find users with at least two orders whose every order total is higher than the one before it.
A correct answer returns 20 rows with one column: user_id.
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
| id | user_id | total | discount | item_count | status | order_date | shipped_date | shipping_city | shipping_country |
|---|---|---|---|---|---|---|---|---|---|
The first rows of each table are shown. See how all the tables relate on the database schema page.
Expected output
| user_id |
|---|
First 5 of 20 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
- Summarising many rows into one value with COUNT, SUM, AVG, MIN or MAX
- Grouping rows with GROUP BY to get one result row per group
- Filtering groups after aggregation with HAVING
- Querying the result of another query with a subquery in FROM
- Reading the previous row's value with LAG()
- Restarting a window calculation for each group with PARTITION BY
Hint and approach
Try the challenge first. Open these only when you need them.
Show the hint
Compare each order with LAG(total), then require that every comparison per user is an increase
Show the step-by-step approach
How the model solution is built, in the order the database evaluates it:
- Build an inner query first (a derived table):
- Read from the
orderstable. - Fetch
totalfrom the previous row withLAG(), ordered byorder_date, restarting for eachuser_id. Where there is no such row the value is NULL.
- Read from the
- Group the rows by
user_id, so the result has one row for each value. - For each group, compute
COUNT(prev)andSUM(total > prev). - Filter the groups in
HAVING: keep those whereCOUNT(prev)is greater than 0, andSUM(total > prev)equalsCOUNT(prev).
Model solution
Checking your session…
What to watch for
Requiring every step to be an increase means the number of increases must equal the number of comparisons. COUNT(prev) counts the comparisons (the first order has no previous one), and SUM(total > prev) counts the increases, because a comparison is 1 or 0 in SQLite. Without the COUNT(prev) > 0 test, single-order users would pass with zero of zero.
- LAG(). LAG() returns NULL for the first row of each partition, and any arithmetic with that NULL is NULL too. Supply a default as the third argument if you need a number.
- PARTITION BY. PARTITION BY is not GROUP BY: it keeps every row and only decides which rows a window function looks at.
- Derived table. Columns computed in the inner query are only visible outside under their alias, so every calculated column there needs a name.
Related SQL challenges
- Find Customers Who Never Went More Than 7 Days Between OrdersSimilar levelHard
- Find Each Customer's Biggest Jump Between Consecutive OrdersSimilar levelHard
- Find Customers with an Above-Average Number of OrdersEasierMedium
- Find the Longest Gap Between Orders for Each CustomerSimilar levelHard
- Calculate the Average Days Between Orders per CustomerSimilar levelHard
Same technique, other tables
More practice on this pattern with different columns:
Keep learning
- Lesson: LAG & LEAD
- Lesson: Window Functions
- Lesson: SQL Subqueries
- Lesson: HAVING Clause
- All SQL practice challenges, by difficulty and topic
- SQL interview questions with answers
- SQL Playground: run any query on the same database