AI для генерации SQL-запросов и схем БД: помощник аналитика в работе с данными

SQL не стал проще за последние 20 лет. JOIN всё так же путают с LEFT JOIN, подзапросы плодят тормоза на проде, а чужая схема из сорока таблиц вызывает желание закрыть ноутбук и пойти за кофе. Но появился инструмент, который меняет правила игры. Нет, он не пишет SQL за вас с закрытыми глазами. Но он сокращает путь от «мне нужны данные о клиентах, которые…» до работающего запроса с EXPLAIN — c часов до минут.

В этом посте — не теория про «AI убьёт профессию», а конкретные промпты и pipeline. Если вам интересно, как LLM справляется с требованиями в целом — загляните в разбор AI для системного анализа, там про полный цикл. А здесь — только про данные.

Почему аналитику нужен AI для SQL

Формально SQL — это навык, который есть в любой вакансии аналитика. На практике — это боль. Потому что настоящее владение SQL начинается не с SELECT * FROM, а с момента, когда вы лезете в пятиэтажный запрос коллеги, написанный три года назад, с тремя вложенными подзапросами и комментарием «потом поправим» (не поправили, конечно).

Проблема распадается на три части:

• Написание нового запроса. Вы знаете, какие данные нужны, но не помните точные названия полей, не уверены, какой JOIN даст правильный результат, и вообще — может, оконная функция будет быстрее подзапроса?
• Разбор чужого запроса. Коллега уволился, а его WITH RECURSIVE на 60 строк висит в проде как чёрный ящик. Вы не знаете, что он считает, правильно ли считает и зачем там пятый JOIN к той же таблице.
• Проектирование схемы. Новая фича требует три таблицы, но как их связать? Какие индексы повесить? Что будет с производительностью на миллионе строк?

LLM закрывает все три направления. Не идеально, но с результатом, который уже можно показывать на код-ревью, а не прятать в корзину.

Pipeline: от вопроса к готовому запросу

Процесс работы с LLM для SQL выглядит как цикл, а не как одна команда. Вы даёте модели контекст (схему, пример данных, бизнес-вопрос), она выдаёт запрос и план выполнения, вы проверяете результат и при необходимости идёте на второй круг.

graph LR
  QUESTION["Вопрос аналитика<br/>«Какие клиенты не делали<br/>заказы больше 30 дней?»"]
  SCHEMA["Схема БД<br/>Описание таблиц,<br/>индексов, связей"]
  LLM["LLM<br/>Генерация SQL"]
  SQL["SQL-запрос<br/>SELECT с JOIN,<br/>GROUP BY, WHERE"]
  EXPLAIN["EXPLAIN<br/>План выполнения,<br/>узкие места"]
  VALIDATE["Валидация<br/>Аналитик проверяет<br/>результат"]
  RESULT["Готовый запрос<br/>+ оптимизированная<br/>схема"]
  
  QUESTION --> LLM
  SCHEMA --> LLM
  LLM --> SQL
  LLM --> EXPLAIN
  SQL --> VALIDATE
  EXPLAIN --> VALIDATE
  VALIDATE --> RESULT
  VALIDATE -.->|"Итерация<br/>при ошибках"| LLM
  
  style QUESTION fill:#f0a500,stroke:#c88400,color:#fff
  style SCHEMA fill:#7b68ee,stroke:#5a4db2,color:#fff
  style LLM fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style SQL fill:#50c878,stroke:#3a9a5c,color:#fff
  style EXPLAIN fill:#50c878,stroke:#3a9a5c,color:#fff
  style VALIDATE fill:#f0a500,stroke:#c88400,color:#fff
  style RESULT fill:#7b68ee,stroke:#5a4db2,color:#fff

На входе — два потока: бизнес-вопрос аналитика (жёлтый, слева) и метаданные схемы БД (фиолетовый). Модель (синий) получает и то, и другое, после чего параллельно выдаёт SQL-запрос и EXPLAIN (зелёные). Оба результата идут на валидацию аналитиком (жёлтый), откуда либо уходят в готовый результат (фиолетовый), либо — если что-то не так — возвращаются на доработку (пунктирная связь). Цикл короткий: обычно одного-двух проходов хватает.

Примечательно, что эта схема работает не только для SELECT, но и для DDL — создания таблиц, индексов и ограничений. Достаточно заменить бизнес-вопрос на «нужна схема для хранения заказов с товарами и статусами».

Часть 1. Пишем SELECT: от вопроса до результата

Шаг 1. Дайте модели схему

Самая частая ошибка — кинуть модели голый вопрос «напиши запрос, который покажет клиентов без заказов за последний месяц» и удивиться, что она выдумала названия таблиц. LLM не знает вашу схему. Чем подробнее вы её опишете, тем точнее будет результат.

Формат не важен: можно копипастой DDL, можно текстовым описанием. Главное — указать названия таблиц, ключевые поля, связи между ними и типы данных (хотя бы примерно). Вот минимальный жизнеспособный контекст:

1
Таблицы:
2

3
1. customers (клиенты):
4
   - id (PK, integer)
5
   - name (text)
6
   - email (text, unique)
7
   - created_at (timestamp)
8
   - status (text: 'active', 'inactive', 'blocked')
9

10
2. orders (заказы):
11
   - id (PK, integer)
12
   - customer_id (FK → customers.id)
13
   - order_date (timestamp)
14
   - total_amount (numeric)
15
   - status (text: 'new', 'processing', 'completed', 'cancelled')
16

17
3. order_items (позиции заказа):
18
   - id (PK, integer)
19
   - order_id (FK → orders.id)
20
   - product_id (FK → products.id)
21
   - quantity (integer)
22
   - price (numeric)
23

24
4. products (товары):
25
   - id (PK, integer)
26
   - name (text)
27
   - category_id (FK → categories.id)
28
   - price (numeric)
29
   - stock_quantity (integer)
30

31
Связи:
32
customers.id ← orders.customer_id
33
orders.id ← order_items.order_id
34
products.id ← order_items.product_id

Схема намеренно учебная. На реальном проекте таблиц будет не четыре, а сорок — и это только те, что относятся к вашему bounded context. Здесь важно дать модели ровно то, что релевантно задаче, а не вывалить весь pg_dump.

Шаг 2. Формулируйте вопрос как бизнес-требование

Не «напиши LEFT JOIN», а «мне нужен список клиентов, которые не делали заказов за последние 30 дней». Почему? Модель лучше понимает бизнес-логику, чем синтаксические конструкции. Она сама решит, какой JOIN уместнее, и объяснит почему.

Промпт:

1
Ты — SQL-разработчик. Ниже — схема БД интернет-магазина.
2
Напиши SQL-запрос (PostgreSQL) для следующей задачи:
3

4
«Получить список клиентов (id, имя, email), которые не делали ни одного
5
заказа за последние 30 дней. Учитывать только активных клиентов
6
(status = 'active'). Отсортировать по дате создания клиента по убыванию.»
7

8
Требования к запросу:
9
1. Используй EXPLAIN (ANALYZE не нужен — запрос ещё не запущен).
10
2. Предложи индексы, которые ускорят выполнение, если их нет.
11
3. Объясни, почему выбран именно такой план выполнения, а не альтернативный.
12
4. Если запрос может дать неочевидный результат при определённых данных —
13
   предупреди об этом.
14

15
Схема БД:
16
[описание схемы из шага 1]

Что получаем на выходе? Модель выдаёт запрос, EXPLAIN, предложения по индексам и комментарий. Обычно качество такое, что после одной-двух правок запрос идёт в работу. Не всегда идеально — но всегда лучше, чем писать с нуля и гуглить синтаксис NOT EXISTS vs LEFT JOIN ... IS NULL, попутно отвлекаясь на Slack.

Шаг 3. Итерация: докручиваем промпт

Первый результат часто компилируется, но не попадает в точность. Модель может перестраховаться и использовать NOT IN вместо NOT EXISTS (что на NULL-ах даст сюрприз), или предложить индекс, который вы уже создали. Второй заход обычно закрывает все вопросы — и в этом главная магия: итерация занимает 30 секунд, а не полчаса гугления.

Промпт для второго раунда:

1
Запрос работает, но есть нюанс:
2

3
1. Клиентская база — 2 млн записей, заказов — 15 млн.
4
2. Поле email может быть NULL для гостевых аккаунтов
5
   (хотя в схеме указано unique — это исторический баг,
6
    который никто не трогает, потому что «работает — не трогай»).
7
3. Индекс на orders.customer_id уже есть.
8
4. Запрос будет запускаться ежедневно в 3 утра по cron.
9

10
С учётом этого — перепиши запрос и обнови EXPLAIN.

На этом этапе модель сама перейдёт с NOT IN на NOT EXISTS (или наоборот, в зависимости от диалекта) и учтёт NULL-ы. Стоит отметить, что такой диалог — это и есть главный юзкейс LLM для SQL: не генерация с первой попытки, а быстрая итеративная доводка.

Часть 2. Разбираем чужой запрос

А вот здесь LLM делает то, на что у человека ушли бы часы. Вы кидаете запрос на 60 строк с WITH RECURSIVE и конструкцией LATERAL JOIN, которую вы видели только в документации PostgreSQL — и получаете построчное объяснение.

Промпт:

1
Ниже — SQL-запрос, написанный бывшим коллегой. Объясни:
2

3
1. Что делает запрос в целом (одно предложение).
4
2. Для каждой CTE, подзапроса и JOIN — объясни, какие данные
5
   отбираются и зачем.
6
3. Какие потенциальные проблемы ты видишь:
7
   - Производительность (отсутствующие индексы, seq scan на больших
8
     таблицах).
9
   - Корректность (NULL-ы, дубликаты, потеря строк).
10
   - Поддерживаемость (избыточная сложность, неочевидная логика).
11
4. Предложи упрощённую версию, если это возможно без потери логики.
12

13
Запрос:
14
[вставить монструозный SQL]

Честно: я проделывал это с тремя реальными продакшен-запросами. В двух случаях модель нашла джойн, который ничего не делал — он фильтровал по полю, которое всегда NULL в этом срезе данных. Коллега добавил его «на всякий случай» три года назад, и с тех пор запрос работал медленнее на 40%. Просто потому, что никто не решался его разобрать. (Да, я тоже не решался, пока LLM не разложила всё по полочкам за минуту.)

Часть 3. Проектируем схему с нуля

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

Промпт:

1
Спроектируй схему БД (PostgreSQL) для модуля промокодов интернет-магазина.
2
Требования:
3

4
1. Промокод может быть:
5
   - Процентным (скидка 10% на весь заказ).
6
   - Фиксированным (скидка 500 ₽).
7
   - На бесплатную доставку.
8

9
2. Ограничения промокода:
10
   - Период действия (дата начала и окончания).
11
   - Максимальное количество использований (общее и на одного
12
     пользователя).
13
   - Минимальная сумма заказа.
14
   - Привязка к конкретным категориям товаров или товарам.
15

16
3. Промокод может быть одноразовым или многоразовым.
17

18
4. Нужно хранить историю применений: кто, когда, к какому заказу,
19
   какая скидка получилась в рублях.
20

21
Выдай:
22
A) DDL (CREATE TABLE) для всех таблиц.
23
B) Список внешних ключей и ограничений (CHECK, UNIQUE).
24
C) Индексы с обоснованием (почему этот индекс, какой тип).
25
D) ER-диаграмму в виде описания связей.
26
E) Предупреждения: где могут быть проблемы при росте данных,
27
   какие ограничения стоит ослабить, если объём вырастет.

Модель за минуту выдаёт 4–5 таблиц с внешними ключами, индексами и даже комментариями COMMENT ON COLUMN. Это не замена архитектору БД (нормальные формы модель может нарушить, если явно не попросить их соблюдать), но это фантастическая стартовая точка. То, на что уходит полдня «а давайте подумаем, как это должно выглядеть», превращается в 10 минут правок готового DDL.

Кстати, о промптах: если вы чувствуете, что упираетесь в потолок «модель генерирует поверхностно», значит, пора разобраться в паттернах промпт-инжиниринга — у меня есть отдельный пост про промпт-инжиниринг для системного аналитика, там про то, как выжимать из LLM глубину.

Что LLM делает плохо в SQL (и где всё ещё нужна голова)

Справедливости ради — вот где модель спотыкается:

Специфический диалект. Модель знает PostgreSQL лучше, чем Oracle, и намного лучше, чем ClickHouse. Если вы работаете с экзотической СУБД — проверяйте каждый синтаксический нюанс. LLM может сгенерировать запрос, который в PostgreSQL отработает, а в вашей БД упадёт с загадочной ошибкой на третьей строке.

Бизнес-логика на уровне данных. Модель не знает, что status = 'active' на самом деле не гарантирует, что клиент платёжеспособен — для этого есть отдельное поле credit_check_passed, которое появилось в схеме через год после запуска и лежит в другой таблице. Эти нюансы — ваша зона ответственности.

Реальные объёмы. EXPLAIN от LLM — это теоретический план выполнения. Модель не видит статистику вашей БД: реальное распределение значений, размер таблиц, актуальность ANALYZE. Она может сказать «этот индекс ускорит запрос» — а на деле селективность такая, что seq scan всё равно будет быстрее. EXPLAIN от LLM — отличная гипотеза, но финальную проверку делаете вы на тестовой копии БД.

Транзакции и блокировки. Модель сгенерирует UPDATE и INSERT, но не предупредит, что конкурентное выполнение на продакшене повесит дедлок. Уровень изоляции транзакций, FOR UPDATE, advisory locks — про это LLM нужно спрашивать явно. Сама она в эту сторону не думает.

Таблица: что LLM делает за аналитика в SQL, а что — нет

Это не silver bullet. LLM — это как продвинутый автодополнитель, который иногда умнее вас, а иногда придумывает несуществующий синтаксис с абсолютно уверенным видом. Доверяй, но проверяй.

Реальный кейс: от идеи до отчёта за 15 минут

Был у меня случай. Прилетает задача от маркетинга: «нужен отчёт по клиентам, которые купили товары из категории X, но не покупали из категории Y за последний квартал». Звучит просто, да? На деле — три JOIN, подзапрос с NOT EXISTS и ещё одна таблица с категориями, которая связана с товарами через промежуточную M2M.

Раньше я бы пошёл по такому маршруту: открыл DBeaver, посмотрел схему, вспомнил, что product_categories — это связка many-to-many, написал первый вариант запроса (он, конечно, дал дубликаты), добавил DISTINCT, понял, что DISTINCT маскирует проблему с JOIN, переписал, проверил на тестовых данных… Минут 40 минимум.

С LLM — алгоритм другой. Кидаю схему, кидаю вопрос маркетинга дословно. Модель выдаёт запрос с корректным NOT EXISTS, предлагает индекс, объясняет план. Запускаю на тестовой копии — работает. Одна правка (нужно исключить заблокированных клиентов, а это фильтр по отдельному полю, который я забыл упомянуть в первом промпте) — и через 15 минут отчёт готов.

Не потому что я разучился писать SQL. А потому что я не трачу время на механическую часть: вспомнить синтаксис NOT EXISTS, проверить, что он корректно обрабатывает NULL-ы, и перебрать три варианта JOIN в уме. Модель делает это быстрее.

Заключение

Системный аналитик, который умеет в SQL, — это ожидание. Системный аналитик, который умеет в SQL и LLM, — это преимущество. Разница не в том, что модель пишет запросы за вас, а в том, что она срезает 80% рутины: гугление синтаксиса, подбор индексов наугад, разбор чужих запросов методом «закомментирую этот JOIN и посмотрю, что сломается».

Главный навык здесь — не SQL и не AI. Это умение задавать правильные вопросы: модели — через промпт, и коду — через EXPLAIN. Если вы освоите этот двойной цикл обратной связи, вы перестанете бояться «того самого запроса», который лежит в репозитории три года. Потому что теперь у вас есть инструмент распутать любой клубок SQL-логики. Быстро. И без желания уйти в отпуск после каждого код-ревью.

P.S. Если вы дочитали и думаете «ну, мои запросы и так работают» — отлично. А теперь вспомните запрос, который работает медленно, но «мы к этому привыкли». И скормите его модели. Удивитесь. Я — удивился.