Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
Зареждане…
Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
Зареждане…
Code Lab е в разработка. Постепенно добавяме нови уроци и подобрения. Прогресът може да бъде изтрит.
SQL / POSTGRESQL / Учене / LESSON 01
DATE пази календарен ден (2024-02-15) без час. TIMESTAMP пази ден и час (2024-02-15 14:30:00). В orders.order_date има само дати. Литерал за дата се пише DATE '2024-02-15' или CAST('2024-02-15' AS DATE); и двата са ясни за PostgreSQL. Датите се сравняват с =, <, <=, >, >= като числа: по-късната дата е по-голяма.
С дата може да се смята: order_date + 7 дава датата след седем дни. При сравнение на DATE с TIMESTAMP датата се третира като полунощ на този ден (2024-02-15 00:00:00), затова '2024-02-15 10:00' е по-късно от дата 2024-02-15.
В тези уроци работим само с фиксирани дати. Не използвай CURRENT_DATE или now() — резултатът би се менял всеки ден и оценяването не може да е предвидимо.
Чести грешки: сравнение с текст без литерал за дата ('15/02/2024' не е ISO формат); бъркане на > и >= на самата граница; очакване, че DATE има час.
Мини пример:
SELECT id, order_date FROM orders WHERE order_date >= DATE '2024-03-01';Работни таблици за тази задача. Оценяването ползва и други набори със същата схема.
| 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 · редът на редовете не се изисква
Очакван резултат (показаните данни):
Зареждане…DATE пази календарен ден (2024-02-15) без час. TIMESTAMP пази ден и час (2024-02-15 14:30:00). В orders.order_date има само дати. Литерал за дата се пише DATE '2024-02-15' или CAST('2024-02-15' AS DATE); и двата са ясни за PostgreSQL. Датите се сравняват с =, <, <=, >, >= като числа: по-късната дата е по-голяма. С дата може да се смята: order_date + 7 дава датата след седем дни. При сравнение на DATE с TIMESTAMP датата се третира като полунощ на този ден (2024-02-15 00:00:00), затова '2024-02-15 10:00' е по-късно от дата 2024-02-15. В тези уроци работим само с фиксирани дати. Не използвай CURRENT_DATE или now() — резултатът би се менял всеки ден и оценяването не може да е предвидимо. Чести грешки: сравнение с текст без литерал за дата ('15/02/2024' не е ISO формат); бъркане на > и >= на самата граница; очакване, че DATE има час.
QUERY STANDBY
›