SQL по описанию: запрос из человеческого вопроса — Промты

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

Когда использовать

У тебя есть база (PostgreSQL/MySQL/ClickHouse) и вопрос «сколько / кто / за период», но писать SQL руками долго или ты не SQL-ниндзя. Роль ИИ — аналитик-инженер данных. Результат: один готовый запрос под твой диалект + объяснение, что он считает, без выдуманных таблиц и полей.

Промт (бери и вставляй)

Ты — инженер данных. Напиши ОДИН SQL-запрос под диалект <ВСТАВЬ: PostgreSQL / MySQL / ClickHouse / SQLite>.

СХЕМА (используй ТОЛЬКО эти таблицы и колонки, ничего не выдумывай):
<ВСТАВЬ DDL ИЛИ ОПИСАНИЕ: таблицы, колонки, типы, ключи и связи>

ВОПРОС: «<ВСТАВЬ ВОПРОС НА РУССКОМ>».

Правила:
1. Если для ответа не хватает поля/таблицы — НЕ выдумывай: перечисли, чего не хватает, и предложи ближайшую трактовку.
2. Делай явные JOIN по ключам, фильтры по датам — через границы [начало, конец), агрегаты — с понятными алиасами.
3. Избегай SELECT * ; выбирай только нужные колонки. Добавь ORDER BY и LIMIT, если уместно.
4. Над запросом — 1–2 строки комментария: что он считает и какие допущения сделаны.
5. Только SELECT. Никаких UPDATE/DELETE/DROP. Если вопрос требует изменения данных — откажись и объясни.

Формат ответа: сначала комментарий-допущения, затем блок ```sql с запросом, затем «Проверь:» — 1 фраза, как быстро убедиться в корректности.

Приём: «привязка к схеме» (schema grounding) — модель видит реальные таблицы и не галлюцинирует имена полей; запрет на запись защищает прод.

Пример заполнения

Диалект: PostgreSQL. Схема: orders(id, user_id, created_at, total, status), users(id, country). Вопрос: «выручка по странам за май 2026 только по оплаченным заказам».

Ожидаемый ответ ИИ: комментарий «считаю сумму total по странам, status='paid', май 2026, границы [2026-05-01, 2026-06-01)»; затем запрос SELECT u.country, SUM(o.total) AS revenue FROM orders o JOIN users u ON u.id = o.user_id WHERE o.status = 'paid' AND o.created_at >= '2026-05-01' AND o.created_at < '2026-06-01' GROUP BY u.country ORDER BY revenue DESC;; «Проверь: сумма по всем странам должна сойтись с общей выручкой за май по оплаченным».

Вариации

Объясни чужой запрос. «Вот SQL — объясни по шагам, что он делает, и найди потенциально медленные места».
Оптимизация. «Запрос медленный на 50 млн строк. Предложи индексы и перепиши без подзапросов в SELECT».
Под BI. «Оформи как вью (CREATE VIEW) для дашборда; параметр периода вынеси отдельно».

Про-советы

Главное — отдать РЕАЛЬНУЮ схему (DDL или хотя бы список колонок с типами). Без неё модель угадывает имена — и запрос падает на первом же прогоне.
Всегда прогоняйте сгенерированный SQL на тестовой копии или с LIMIT, прежде чем верить числам: синтаксически верный запрос может считать не то (двойной счёт на JOIN — классика).
Жёстко фиксируйте «только SELECT»: это и безопасность (никаких случайных DELETE), и сигнал модели не «помогать» изменением данных.