The Running Total

The chart the board at Whetcode Supply actually looks at is the one that only goes up: money taken so far, plotted one sale at a time from the shop's first order onward. Each point is everything earned up to and including that order, so the line climbs by the value of each new sale and never falls.

The slide shows the opening stretch — the first five sales, back when each one visibly moved the line. Two of those sales landed on the same day, so the sequence needs a rule for which of them comes first.

orders — one row per order. customer_id is the id of the customer who placed it, product_id the id of the item bought, quantity how many units of that item, and order_date the day it was placed. An order row covers one item only.

products — the catalogue, one row per item on sale. price is what a single unit costs, in dollars.

The tables already exist in the database — there is nothing to create or load.

Task: Write a query returning two columns, order_date (the day the order was placed, exactly as stored) and cumulative_revenue (everything the shop had taken up to and including that order, rounded to two decimal places), returning only the first five rows. Take the orders oldest first, using the order's own id to separate two placed on the same day, smaller id first. An order's own value is its item's price times its number of units. Because two orders share a date, order_date appears twice in the output with two different running totals.

Example output — shape only, on invented orders. The first two share a date and carry two different running figures, because the total advances one order at a time rather than one day at a time: