SELECT: dohvaćamo podatke koji nam trebaju

Majstorska provjera: SELECT na djelu

22 min
What you'll learn
  • učvrstit ćeš vještinu slaganja potpunog SELECT-a: izbor stupaca, aliase, filtre WHERE, BETWEEN/IN/LIKE, sortiranje s LIMIT — na zadacima vježbaonika
  • dokazat ćeš sposobnost pronalaženja uzroka „tihih” pogrešaka: usporedbe s NULL, OR bez zagrada, CASE bez ELSE, LIMIT bez ORDER BY
  • učvrstit ćeš navike pouzdanog upita: zagrade u miješanim uvjetima, izričit ELSE, sortiranje s jedinstvenim ključem

Učvrstimo SELECT na stvarnim zadacima

QUERY gasi suvišne ploče. U dvorani ostaju jedan terminal i tri zadatka: ispit za prvu propusnicu. Akademija ne vjeruje riječima — samo upitima.

Složio si osnovni komplet arhivara-čitača: biraš stupce koji ti trebaju, daješ im razumljive aliase, filtriraš retke pomoću WHERE, pažljivo postupaš s NULL, koristiš BETWEEN/IN/LIKE, zadaješ redoslijed pomoću ORDER BY/LIMIT, uklanjaš duplikate pomoću DISTINCT i dodaješ jednostavnu logiku pomoću CASE.

Sada to učvrsti na zadacima iz vježbaonika: nalik su običnim pitanjima „Kotomarketu” — što pokazati, što odsjeći i kako označiti rezultat. Riješi ih u uredniku (otvorit će se u novoj kartici), i blok ispod označit će se kao prijeđen.

Polumračna dvorana, jedan terminal s tri zadatka i zaključan, šifrirani blok podataka koji treperi duboko u hologramu
Ispit za prvu propusnicu: tri upita između tebe i sljedeće razine arhiva.

Как читать полный SELECT

Когда запрос становится длиннее трёх строк, новичок часто теряется. Кажется, что SQL выполняется строго сверху вниз, как текст.

Но удобнее читать запрос по смысловым слоям.

Например:

SELECT
    name,
    category,
    price,
    CASE
      WHEN price < 1500 THEN 'дешёвый'
      WHEN price < 4000 THEN 'средний'
      ELSE 'дорогой'
    END AS segment
FROM products
WHERE category IN ('Книги', 'Игрушки')
  AND price BETWEEN 1000 AND 3000
ORDER BY price DESC, id
LIMIT 5;

Такой запрос можно разобрать по шагам.

Сначала источник:

FROM products

База берёт таблицу товаров.

Потом фильтр строк:

WHERE category IN ('Книги', 'Игрушки')
  AND price BETWEEN 1000 AND 3000

Остаются только книги и игрушки с ценой от 1000 до 3000 включительно.

Потом список столбцов и вычислений:

SELECT
    name,
    category,
    price,
    CASE ... END AS segment

Запрос показывает название, категорию, цену и добавляет сегмент через CASE.

Потом порядок:

ORDER BY price DESC, id

Сначала дорогие товары, а при одинаковой цене — стабильная сортировка по id.

И только после этого ограничение:

LIMIT 5

Остаются первые пять строк уже после сортировки.

Главная мысль:

LIMIT не выбирает «лучшие» строки сам. Он просто берёт верхушку того порядка, который ты задал через ORDER BY.

Что делает запрос надёжным

На этом уровне важно не просто получить зелёную галочку. Важно начать думать как человек, который понимает, почему запрос вернул именно эти строки.

Надёжный запрос обычно обладает тремя признаками.

Первый признак — он явно говорит, какие строки нужны.

Плохо, когда условие приходится угадывать по куску логики. Хорошо, когда WHERE читается как точное правило:

WHERE category IN ('Книги', 'Игрушки')
  AND price BETWEEN 1000 AND 3000

Второй признак — он явно говорит, в каком порядке нужен результат.

Если важны самые дорогие товары, самые свежие заказы или первые пользователи по алфавиту, это должно быть записано в ORDER BY:

ORDER BY price DESC, id

Третий признак — он не прячет неопределённость.

Если в данных может быть NULL, запрос должен учитывать это явно:

WHERE city IS NULL

или:

WHERE city <> 'Москва'
   OR city IS NULL

Если в CASE есть строки, которые не попали ни в одну ветку, лучше заранее решить, что с ними делать:

ELSE 'другой статус'

Если порядок при равных значениях важен, его нужно добить уникальным ключом:

ORDER BY price DESC, id

На маленьких учебных таблицах многие недочёты незаметны. Но в реальной базе такие мелочи превращаются в тихие ошибки: запрос выполняется без падения, но результат оказывается не тем.

Тихие ошибки: когда запрос работает, но врёт

Самые неприятные ошибки в SQL не всегда выглядят как красная ошибка синтаксиса.

Гораздо чаще запрос запускается, возвращает таблицу, но строки в ней не те.

Например, сравнение с NULL:

WHERE city = NULL

Синтаксически запрос может быть корректным, но он не найдёт строки, где города нет. Для NULL нужна проверка:

WHERE city IS NULL

Или условие со смешанными AND и OR:

WHERE category = 'Книги'
   OR category = 'Игрушки'
  AND price < 3000

Такой запрос читается глазами как:

книги или игрушки, и цена меньше 3000

Но SQL сначала связывает AND, а потом OR. Поэтому фактическая логика другая:

WHERE category = 'Книги'
   OR (category = 'Игрушки' AND price < 3000)

Если тебе нужно применить цену к обеим категориям, нужны скобки:

WHERE (category = 'Книги' OR category = 'Игрушки')
  AND price < 3000

Или так, ещё чище:

WHERE category IN ('Книги', 'Игрушки')
  AND price < 3000

Ещё один тихий сбой — CASE без ELSE:

CASE
  WHEN status = 'paid' THEN 'оплачен'
  WHEN status = 'pending' THEN 'ожидает'
END AS status_label

Если появится статус cancelled, метка станет NULL. Иногда это нормально, но чаще для отчёта лучше явно написать запасной вариант:

ELSE 'другой статус'

И наконец, LIMIT без ORDER BY:

SELECT name, price
FROM products
LIMIT 5;

Этот запрос не выбирает топ-5. Он выбирает любые первые пять строк в том порядке, который база решила вернуть сейчас.

Для топа нужен критерий:

SELECT name, price
FROM products
ORDER BY price DESC, id
LIMIT 5;

Тихие ошибки опасны именно тем, что база не спорит. Она выполняет то, что написано. Даже если ты имел в виду другое.

КВЕРИ: Архив не читает намерения. Он читает запрос. Если мысль не записана явно, её не существует.

Перед отправкой запроса

Перед тем как отправить решение в тренажёре, полезно быстро пройтись по запросу глазами.

Сначала проверь, что ты выбрал ровно нужные столбцы.

Если в задаче просят:

name, price

не нужно оставлять:

SELECT *

Даже если так проще во время черновика, финальный ответ должен показывать то, что просит задача.

Потом проверь фильтр.

Если в условии задачи есть «от 1000 до 3000 включительно», хорошо подходит:

BETWEEN 1000 AND 3000

Если сказано «категория Книги или Игрушки», читаемее использовать:

IN ('Книги', 'Игрушки')

Если нужно «начинается с», подойдёт:

LIKE 'К%'

Если нужно «содержит», подойдёт:

LIKE '%К%'

Но помни: ведущий % может быть дорогим на больших таблицах.

Потом проверь NULL.

Если нужно найти отсутствующее значение, не пиши:

= NULL

Пиши:

IS NULL

Если нужно исключить значение, но сохранить строки с NULL, добавь это явно:

WHERE city <> 'Москва'
   OR city IS NULL

Потом проверь сортировку.

Если в задаче есть слова:

самые дорогие
самые дешёвые
последние
первые
топ

почти наверняка нужен ORDER BY.

Если есть ограничение количества строк, почти наверняка нужен LIMIT.

И наконец, если сортируешь по столбцу, где возможны одинаковые значения, добавь уникальный ключ:

ORDER BY price DESC, id

Так результат будет стабильным.

Что ты уже умеешь к концу модуля

Этот модуль был про чтение строк.

Ты ещё не считаешь выручку, средний чек и количество заказов по группам — это следующий уровень. Но ты уже умеешь достать из таблицы именно тот слой данных, который нужен для ответа.

Тебе доступен базовый маршрут:

SELECT ...
FROM ...
WHERE ...
ORDER BY ...
LIMIT ...

Ты понимаешь, зачем нужны :

price * stock AS stock_value

Ты умеешь работать с отсутствующими значениями:

IS NULL
IS NOT NULL
COALESCE(...)

Ты умеешь задавать короткие фильтры:

BETWEEN
IN
LIKE

Ты умеешь получать словарь значений:

SELECT DISTINCT status
FROM orders;

Ты умеешь добавлять в выдачу человеческие метки:

CASE
  WHEN ... THEN ...
  ELSE ...
END

И главное — ты уже знаешь, что корректный синтаксис не гарантирует корректную мысль.

SQL может выполнить запрос идеально и всё равно вернуть не то, что ты хотел, если условие записано неточно.

Interview question

Pitanje s razgovora za posao: upit je sintaktički ispravan, ali retci „neprimjetno” nestaju iz ispisa ili dobivaju krive vrijednosti. Navedi tipične uzroke.

Snažan odgovor: klasična četvorka ove razine propusnice. (1) Usporedbe s NULL: =, <> i NOT IN s popisom u kojem ima daju — redak ne prolazi WHERE; liječi se s IS NULL, IS DISTINCT FROM, COALESCE. (2) OR bez zagrada: AND veže jače, i uvjet se grupira drukčije nego što se čita. (3) CASE bez ELSE vraća NULL za nepokrivene retke, a WHEN NULL u jednostavnom obliku je mrtav. (4) LIMIT bez ORDER BY daje „nekakve” retke: redoslijed bez sortiranja nije zajamčen. Na razgovoru se ne cijeni popis, nego navika: zagrade u miješanim uvjetima, izričit ELSE, izričito sortiranje s jedinstvenim ključem.

QUERY: From here the archive opens only to those who count. Revenue, average order value, groups — the next level of clearance.