Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
Зареждане…
Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
Зареждане…
Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
SQL / POSTGRESQL / Учене / LESSON 09
Когато в OVER има ORDER BY, агрегатът става натрупващ: SUM(total) OVER (ORDER BY order_date, id) събира всички редове от началото до текущия. Това е „текущото салдо“ или натрупаните продажби във времето. С PARTITION BY натрупването започва отначало във всяка група.
Важно: ORDER BY вътре в OVER е само за прозореца. Той НЕ подрежда крайния резултат — ако искаш редовете да се виждат подредени, добави отделен ORDER BY накрая и обикновено със същите колони.
Равните стойности в OVER (ORDER BY order_date) са „връстници“: по подразбиране прозорецът е RANGE от началото до текущия ред И неговите връстници, затова две поръчки от един ден получават една и съща натрупана сума. За натрупване ред по ред добави уникален ключ: ORDER BY order_date, id.
Чести грешки: OVER (ORDER BY order_date) без tie-breaker; липсващ краен ORDER BY; очакване, че OVER ORDER BY е сортирането на резултата; натрупване върху NULL клиент, ако не е желано.
Мини пример:
SELECT id, order_date, total, SUM(total) OVER (ORDER BY order_date, id) AS running_total FROM orders ORDER BY order_date, id;
Работни таблици за тази задача. Оценяването ползва и други набори със същата схема.
| id | name | category | price |
|---|---|---|---|
| 1 | Atlas | books | 30 |
| 2 | Novel | books | 15 |
| 3 | Comic | books | 14.99 |
| 4 | Lamp | home | 29.99 |
| 5 | Vase | home | 30 |
| 6 | Rug | home | 45 |
| 7 | Hammer | tools | 15 |
| 8 | Drill | tools | 60 |
| 9 | Tape | tools | 15 |
| 10 | Candle | NULL | 8.5 |
| 11 | Gift Card | NULL | 25 |
| id | name | city |
|---|---|---|
| 1 | Mira | Sofia |
| 2 | Niko | Varna |
| 3 | Iva | Sofia |
| 4 | Alex | NULL |
| 5 | Boris | Plovdiv |
| 6 | Lena | Varna |
| 7 | Petya | Sofia |
| id | customer_id | total | order_date |
|---|---|---|---|
| 1 | 1 | 120 | 2024-01-05 |
| 2 | 1 | 35.5 | 2024-01-20 |
| 3 | 2 | 40 | 2024-01-20 |
| 4 | 3 | 99.99 | 2024-01-31 |
| 5 | NULL | 60 | 2024-02-01 |
| 6 | 1 | 40 | 2024-02-01 |
| 7 | 2 | 75.25 | 2024-02-14 |
| 8 | 3 | 100 | 2024-02-15 |
| 9 | 5 | 22 | 2024-02-15 |
| 10 | 1 | 39.99 | 2024-02-29 |
| 11 | 2 | 55 | 2024-03-01 |
| 12 | 3 | 18 | 2024-03-10 |
| 13 | 1 | 130 | 2024-03-15 |
| 14 | 2 | 40 | 2024-03-15 |
| 15 | 2 | 12.5 | 2024-03-31 |
| 16 | 3 | 47 | 2024-04-01 |
Очаквани колони: id, order_date, total, running_total · редът на редовете се проверява
Очакван резултат (показаните данни):
Зареждане…Когато в OVER има ORDER BY, агрегатът става натрупващ: SUM(total) OVER (ORDER BY order_date, id) събира всички редове от началото до текущия. Това е „текущото салдо“ или натрупаните продажби във времето. С PARTITION BY натрупването започва отначало във всяка група. Важно: ORDER BY вътре в OVER е само за прозореца. Той НЕ подрежда крайния резултат — ако искаш редовете да се виждат подредени, добави отделен ORDER BY накрая и обикновено със същите колони. Равните стойности в OVER (ORDER BY order_date) са „връстници“: по подразбиране прозорецът е RANGE от началото до текущия ред И неговите връстници, затова две поръчки от един ден получават една и съща натрупана сума. За натрупване ред по ред добави уникален ключ: ORDER BY order_date, id. Чести грешки: OVER (ORDER BY order_date) без tie-breaker; липсващ краен ORDER BY; очакване, че OVER ORDER BY е сортирането на резултата; натрупване върху NULL клиент, ако не е желано.
QUERY STANDBY
›