Почему SQL до сих пор управляет всем

Декларативный, а не императивный

В большинстве языков ты пишешь как: пройди по массиву, сравни каждый элемент, добавь совпадения в новый список. SQL — наоборот. Ты пишешь что хочешь и молчишь о том, как:

SELECT name, email
FROM users
WHERE country = 'JP'
ORDER BY created_at DESC
LIMIT 10;

Ты не написал ни одного цикла. Не сказал «используй индекс по country», «сортируй quicksort» или «читай диск страницами по 8 КБ». Ты описал множество строк — японские пользователи, новейшие сверху, первые десять — и отдал задачу движку. Postgres разбирается с остальным: какой индекс взять, сортировать в памяти или сбросить на диск, сколько CPU-воркеров бросить на запрос.

У этого разделения есть имя: запрос — это логика (что), план — физика (как). Логический слой твой. Физический — планировщика. Следующий урок вскрывает планировщик; пока важно лишь то, что эта стена существует.

Почему это и есть долговечная идея

Поскольку ты не закодировал как, движок волен это менять. Тот же SELECT, что сканировал таблицу на 10 000 строк в 2009-м, сегодня идёт по B-tree индексу (древовидная структура, по которой Postgres ищет строку за O(log n) шагов) на 500 миллионах строк в 2026-м — тот же текст, совершенно другое физическое выполнение. Добавь индекс сегодня вечером — и завтрашний запрос станет в 600 раз быстрее без единой правки кода. Попробуй это с написанным вручную циклом.

Именно поэтому SQL пережил десятилетие NoSQL. Документные и key-value хранилища выиграли отдельные битвы (масштабирование записи, схемалесс-блобы), но большинство из них отрастили язык запросов, подозрительно похожий на SQL, потому что декларативную модель действительно трудно превзойти в вопросе «дай строки, подходящие под условие, соединённые с теми, сгруппированные и отсортированные». Сам Postgres впитал лучшую идею NoSQL — JSONB-документы — не отказавшись от реляционного ядра (встретишь это в разделе 06).

Мышление множествами, а не строками

Спроси себя: когда твой ORM шлёт 80 запросов, чтобы отрисовать одну страницу, — это проблема фреймворка или проблема мышления? Это проблема мышления. SQL работает с множествами, целиком и сразу, а не построчно. Здесь нет «текущей строки», как в цикле. WHERE концептуально применяется ко всему множеству как бы параллельно; JOIN — это комбинация двух множеств; GROUP BY сворачивает множество в корзины.

Практическое следствие: написать в приложении цикл, который шлёт по одному запросу на строку — паттерн N+1 запросов — самая частая ошибка производительности в продакшне. Один запрос на 1000 строк — это один round trip (сетевой туда-обратно); 1000 запросов по одной строке — это 1000 round trip’ов и часто в 100 раз медленнее. Весь смысл SQL — протолкнуть операцию над множеством вниз, в движок, а не тянуть строки наверх и крутить цикл в своём коде.