> Почему нельзя заменить WITH (CTE) на подзапрос в SQL (Go)

Короткий ответ

На самом деле CTE (WITH) в большинстве случаев можно заменить на подзапрос - это синтаксический сахар. Но есть важные исключения: рекурсивные CTE, которые подзапросом не выразить, и случаи, когда CTE используется несколько раз - тогда подзапрос приведёт к дублированию кода и потенциально к повторному выполнению. Также CTE улучшает читаемость и позволяет материализацию в некоторых СУБД (например, PostgreSQL с MATERIALIZED).

Подробное объяснение

CTE и подзапрос - это два способа описать временный набор строк. С точки зрения оптимизатора в большинстве СУБД они эквивалентны: планировщик разворачивает CTE в подзапрос или инлайнит его. Однако есть различия:

1. Рекурсия - единственное, что принципиально нельзя сделать подзапросом. Рекурсивный CTE (WITH RECURSIVE) позволяет обходить деревья, графы, генерировать последовательности. Подзапрос не может ссылаться сам на себя.

2. Многократное использование - если CTE используется в нескольких местах основного запроса, подзапрос придётся дублировать. Это не только ухудшает читаемость, но и может привести к повторному сканированию одних и тех же данных.

3. Материализация - в PostgreSQL (и некоторых других СУБД) CTE может быть материализован (выполнен один раз и сохранён во временной памяти), а подзапрос - нет. Это trade-off: материализация полезна, если CTE тяжёлый и используется несколько раз, но вредна, если он лёгкий и его можно инлайнить.

4. Читаемость и поддержка - CTE позволяет дать имя подзапросу и вынести его наверх, что упрощает чтение сложных запросов. Это не техническое, а организационное преимущество.

Важно понимать: утверждение "нельзя заменить" неверно в общем случае. Правильнее сказать: "в большинстве случаев можно, но есть исключения".

На практике

В Go-разработке с SQL (обычно через database/sql, sqlx, pgx) вы чаще работаете с готовыми запросами, чем пишете их на лету. Но при проектировании сложных выборок:

• Если запрос рекурсивный (например, обход дерева категорий, иерархия сотрудников) - используйте WITH RECURSIVE, подзапрос не подойдёт.
• Если один и тот же подзапрос встречается в запросе дважды - вынесите его в CTE, чтобы не дублировать и не рисковать рассинхронизацией.
• Если вы пишете запрос для PostgreSQL и хотите контролировать материализацию - используйте WITH ... AS MATERIALIZED или WITH ... AS NOT MATERIALIZED.
• Для простых одноразовых подзапросов разницы нет - выбирайте то, что читается лучше.

Пример кода

Рекурсивный CTE - то, что нельзя заменить подзапросом:

SQL
WITH RECURSIVE org_tree AS (
  SELECT id, name, manager_id
  FROM employees
  WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.manager_id
  FROM employees e
  JOIN org_tree ot ON e.manager_id = ot.id
)
SELECT * FROM org_tree;

Попытка сделать то же самое подзапросом невозможна - подзапрос не может ссылаться сам на себя.

Пример, где CTE просто удобнее:

SQL
WITH active_users AS (
  SELECT user_id, COUNT(*) AS cnt
  FROM orders
  WHERE created_at > now() - interval '30 days'
  GROUP BY user_id
)
SELECT u.name, a.cnt
FROM users u
JOIN active_users a ON a.user_id = u.id
WHERE a.cnt > 5;

Эквивалент с подзапросом будет работать так же, но менее читаем.

Как отвечать на собеседовании

Начните с того, что утверждение в вопросе не совсем корректно: в большинстве случаев CTE можно заменить подзапросом. Затем перечислите исключения: рекурсия, многократное использование, материализация. Упомяните, что с точки зрения оптимизатора разницы часто нет. Если собеседник настаивает на "нельзя" - уточните, что именно он имеет в виду: возможно, речь о конкретной СУБД или о рекурсивных CTE.

Что проверяет интервьюер

Интервьюер проверяет:

• понимание разницы между синтаксическим сахаром и реальными возможностями SQL;
• знание рекурсивных запросов;
• понимание работы оптимизатора и материализации;
• умение рассуждать о trade-off между читаемостью и производительностью.

Типичные ошибки

• Утверждать, что CTE всегда быстрее или всегда медленнее подзапроса - это зависит от СУБД и данных.
• Забывать про WITH RECURSIVE как единственное принципиальное отличие.
• Говорить, что CTE выполняется один раз, а подзапрос - каждый раз. В PostgreSQL это верно только для материализованных CTE, и то не всегда.
• Путать CTE с временными таблицами - это разные вещи.