CodeRang
Профессии

SQL для разработчиков: практика backend-запросов

SQL для разработчиков нужен для чтения и изменения данных, которые использует приложение. Помимо SELECT и JOIN, backend-разработчику важно понимать пагинацию, транзакции, индексы, агрегаты и поведение запросов при росте объёма данных.

Обновлено · Команда SQL Arena

Что потренируете

  • JOIN и агрегации в прикладных запросах
  • пагинация и стабильная сортировка
  • INSERT, UPDATE, DELETE и upsert
  • транзакции, ограничения и целостность данных
  • индексы, EXPLAIN и поиск N+1

Пример задачи в тренажёре

Так выглядит задача в SQL Arena: условие, редактор, результат и схема базы.

Пред.След.Случайная
ЗаданиеОтправкиAI Mentor
Какие активные товары смотрели чаще всего

Есть каталог products и журнал просмотров product_views. Получите четыре активных товара с наибольшим числом просмотров. Выведите id, name и количество просмотров как view_count. При одинаковом числе просмотров товар с меньшим id должен идти раньше.

Запрос 1PostgreSQLv16
SELECT p.id, p.name, COUNT(v.id) AS view_count
FROM products p
JOIN product_views v ON v.product_id = p.id
WHERE p.is_active = TRUE
GROUP BY p.id, p.name
ORDER BY view_count DESC, p.id
LIMIT 4;
Отправить
Результатproductsproduct_views
Ответ принят

Разбор SQL-запроса для backend-разработчика

Запрос начинается с products, потому что именно у товара хранится признак активности. Затем JOIN product_views связывает каждое событие просмотра с товаром через product_id. Обычный JOIN, а не LEFT JOIN, здесь уместен: в итог нужны товары, которые действительно просматривали. Условие p.is_active = TRUE отсекает отключённые позиции до формирования результата.

После соединения один товар может занимать несколько строк: по одной на каждый просмотр. Поэтому данные группируются по p.id и p.name, а COUNT(v.id) считает события внутри каждой группы. Это типичный backend-запрос: данные нормализованы по разным таблицам, а API должен вернуть уже собранный показатель, например популярность товара.

ORDER BY view_count DESC, p.id решает две задачи. Сначала товары сортируются по числу просмотров, затем одинаковые значения получают стабильный порядок по идентификатору. Только после этого применяется LIMIT 4. Такой дополнительный критерий особенно важен для API и пагинации: если сортировка неоднозначна, строки с одинаковым значением могут менять позиции между запросами.

SQL для backend-разработчика включает не только выборку данных, но и операции INSERT, UPDATE и DELETE, работу с транзакциями и проектирование запросов под API. Отдельная тема — пагинация. LIMIT и OFFSET просты, но при больших смещениях могут требовать обработки большого числа строк, поэтому для последовательной выдачи часто применяют keyset pagination по стабильному уникальному ключу. Разработчику также важно понимать назначение индексов и смотреть план выполнения, когда запрос начинает читать значительно больше данных, чем требуется для результата.

SQLPostgreSQL v16
SELECT p.id, p.name, COUNT(v.id) AS view_count
FROM products p
JOIN product_views v ON v.product_id = p.id
WHERE p.is_active = TRUE
GROUP BY p.id, p.name
ORDER BY view_count DESC, p.id
LIMIT 4;
Результат запроса
idnameview_count
1Mechanical Keyboard3
2USB-C Hub2
5Studio Microphone2
3Web Camera1

Типичные ошибки разработчиков в SQL

01

LIMIT без стабильной сортировки

Если оставить только ORDER BY view_count DESC, два товара с одинаковым количеством просмотров не обязаны возвращаться в одном и том же порядке. Для одной страницы это может быть незаметно, а при пагинации приводит к повторяющимся или пропущенным строкам.

02

Подсчёт после неправильного JOIN

Если соединить таблицы не по v.product_id = p.id, строки начнут размножаться. COUNT честно посчитает уже ошибочный набор, поэтому результат может выглядеть правдоподобно, но быть сильно завышенным.

03

N+1 вместо одного запроса

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

Задачи по теме в тренажёре

Трек «SQL для Backend-разработчика»

SQL для бэкендера лучше тренировать на задачах, похожих на операции реального сервиса. В SQL Arena есть отдельный трек «SQL для Backend-разработчика» из 60 задач. В нём встречаются чтение и изменение данных, работа со связями, агрегаты и более сложные выборки. Начать можно с бесплатных Easy-задач: например, удалить записи по условию, выбрать объекты недвижимости в нужном городе или массово изменить значения сотрудников. Дальше идут задачи уровня Medium, где приходится работать с оконными функциями, рейтингами, расписаниями и расчётами по группам. Всего в тренажёре 1 192 задачи. Для каждой задачи используются свои таблицы, поэтому нельзя привыкнуть к одной учебной схеме. PostgreSQL, MySQL, ClickHouse и BigQuery работают в отдельных песочницах прямо в браузере. Ответ проверяется на скрытых данных, а не простым сравнением текста запроса с шаблоном. Если запрос не проходит, AI-ментор может дать подсказку или объяснить ошибку; бесплатно доступно 10 таких обращений. Для анализа запросов есть EXPLAIN и ER-диаграммы схем. Отдельный режим «Собеседование» запускается с серверным таймером и без подсказок, а после сессии показывает отчёт; бесплатно его можно проходить один раз в день. Кроме трека для backend-разработчиков, доступны 12 профессиональных треков и 10 курсов, где теория сразу закрепляется задачей в уроке. На бесплатном тарифе без карты открыты 292 задачи во всех четырёх диалектах.

Частые вопросы

Какой SQL нужен разработчику?

Разработчику полезно уверенно владеть SELECT, JOIN, GROUP BY, подзапросами, CTE, INSERT, UPDATE и DELETE. Для backend также важны транзакции, индексы, ограничения, пагинация и базовое понимание планов выполнения.

Что должен знать SQL backend-разработчик?

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

Как использовать SQL в backend-разработке?

Backend использует SQL для получения данных по запросу API, сохранения изменений, проверки связей и построения агрегированных результатов. Запросы могут выполняться напрямую или через библиотеку либо ORM, но принципы работы SQL остаются теми же.

Какую пагинацию использовать в SQL?

LIMIT с OFFSET подходит для простых случаев и перехода на произвольную страницу. Для последовательного чтения больших наборов данных часто используют keyset pagination, где следующая выборка начинается после значения стабильного ключа из предыдущей страницы.

Практика SQL для разработчиков на задачах

Перейдите в трек «SQL для Backend-разработчика»: 60 задач от базовых операций с данными до запросов, которые требуют агрегаций, оконных функций и аккуратной работы со связями. Первые Easy-задачи можно решать бесплатно без карты.

Открыть трек для Backend-разработчика