Как я перестал писать SQL руками: 12 промтов, которые заменили мне аналитика и DBA

Вступление

Каждое утро в нашей компании начиналось одинаково: менеджеры присылали запросы вроде «дай динамику продаж по регионам за квартал», «почему упала конверсия в корзину», «сколько пользователей вернулись через месяц». Я открывал pgAdmin, смотрел на пустой экран и понимал, что сейчас потрачу два часа на написание сложного запроса с JOIN, оконными функциями и подзапросами. А потом ещё час — на оптимизацию, потому что без индексов всё тормозило.

Знакомо? Если вы работаете с данными, то наверняка проходили через это. Но в 2026 году у нас есть мощный инструмент — большие языковые модели, которые умеют генерировать SQL. Я решил проверить, насколько хорошо они справляются с реальными задачами аналитика. Результат меня удивил: я сократил время написания запросов в 10 раз, а многие запросы стали даже лучше, чем я писал сам. В этой статье я поделюсь 12 промтами, которые реально работают, и покажу, как они помогли мне ускорить аналитику без привлечения DBA.

Базовые промты: для тех, кто только начинает

Промт 1. Перевод бизнес-задачи в SQL

Задача: Сформулировать SQL-запрос по описанию на естественном языке.

Промт:

Ты — эксперт по PostgreSQL. Переведи следующую бизнес-задачу в SQL-запрос. Опиши, что делает каждый блок запроса. Задача: «Показать топ-10 клиентов по сумме заказов за последний месяц, с указанием количества заказов и средней суммы чека. Учитывать только завершённые заказы.»

Пример результата:

SELECT 
    c.customer_id,
    c.name,
    COUNT(o.order_id) AS order_count,
    SUM(o.total_amount) AS total_sum,
    AVG(o.total_amount) AS avg_check
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.status = 'completed'
  AND o.order_date >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'
GROUP BY c.customer_id, c.name
ORDER BY total_sum DESC
LIMIT 10;

Почему это работает: Модель понимает контекст и генерирует корректный синтаксис PostgreSQL. Вы можете уточнять задачу, добавляя условия, и получать готовый запрос.

Промт 2. Объяснение сложного запроса

Задача: Понять, что делает существующий SQL-запрос.

Промт:

Объясни, что делает этот SQL-запрос на PostgreSQL. Разбей на части и опиши каждую. Вот запрос:

WITH ranked AS (
    SELECT 
        product_id,
        category_id,
        revenue,
        ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY revenue DESC) AS rn
    FROM sales
)
SELECT * FROM ranked WHERE rn <= 3;

Пример результата:

Этот запрос использует CTE (Common Table Expression) с именем ranked. Внутри CTE для каждого продукта вычисляется revenue и присваивается номер строки (ROW_NUMBER) в пределах категории, отсортированной по убыванию выручки. Затем внешний запрос выбирает только те строки, где rn <= 3, то есть топ-3 продукта по выручке в каждой категории.

Польза: Это незаменимо при работе с чужим кодом или когда вы возвращаетесь к своим старым запросам.

Промт 3. Написание JOIN-запросов

Задача: Соединить несколько таблиц правильно.

Промт:

Напиши SQL-запрос для PostgreSQL, который соединяет таблицы users, orders и order_items. Нужно получить: имя пользователя, дату заказа, название товара и количество. Используй LEFT JOIN, чтобы включить пользователей без заказов. Покажи результат для первых 10 строк.

Пример результата:

SELECT 
    u.name,
    o.order_date,
    p.product_name,
    oi.quantity
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
LEFT JOIN order_items oi ON o.order_id = oi.order_id
LEFT JOIN products p ON oi.product_id = p.product_id
ORDER BY u.name, o.order_date
LIMIT 10;

Важно: Модель правильно выбирает тип JOIN и порядок соединения, что экономит время на отладку.

Продвинутые промты: когда нужно больше

Промт 4. Оптимизация запроса с помощью индексов

Задача: Ускорить медленный запрос.

Промт:

Вот SQL-запрос на PostgreSQL. Он выполняется очень медленно на таблице с 10 миллионами строк. Предложи, какие индексы создать для ускорения, и объясни, почему они помогут. Запрос:

SELECT * FROM orders 
WHERE customer_id = 12345 
  AND order_date BETWEEN '2026-01-01' AND '2026-06-30';

Пример результата:

Для этого запроса оптимальны два индекса:
1. CREATE INDEX idx_orders_customer_id ON orders (customer_id);
2. CREATE INDEX idx_orders_customer_date ON orders (customer_id, order_date);

Первый индекс ускорит фильтрацию по customer_id, второй — по диапазону дат в рамках конкретного клиента. PostgreSQL может использовать композитный индекс для обоих условий, что значительно сократит время выполнения.

Экспертный совет: Всегда проверяйте план выполнения (EXPLAIN ANALYZE) после создания индексов — иногда оптимизатор выбирает другой путь.

Промт 5. Использование оконных функций

Задача: Вычислить скользящее среднее или ранжирование.

Промт:

Напиши SQL-запрос на PostgreSQL для расчёта скользящего среднего продаж за 7 дней по каждому продукту. Используй оконную функцию. Таблица sales (sale_date date, product_id int, amount numeric).

Пример результата:

SELECT 
    sale_date,
    product_id,
    amount,
    AVG(amount) OVER (
        PARTITION BY product_id 
        ORDER BY sale_date 
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS moving_avg_7d
FROM sales
ORDER BY product_id, sale_date;

Применение: Это классика аналитики — тренды, сезонность, аномалии. Модель корректно использует синтаксис оконных функций.

Промт 6. Написание хранимой процедуры

Задача: Автоматизировать повторяющиеся действия.

Промт:

Создай хранимую процедуру на PostgreSQL, которая обновляет статус заказов на 'expired', если дата оплаты просрочена более чем на 30 дней. Процедура должна принимать параметр days (количество дней просрочки). Используй язык plpgsql.

Пример результата:

CREATE OR REPLACE FUNCTION expire_orders(days INT)
RETURNS VOID AS $$
BEGIN
    UPDATE orders
    SET status = 'expired'
    WHERE status = 'pending'
      AND payment_due_date < CURRENT_DATE - days;
END;
$$ LANGUAGE plpgsql;

Замечание: Модель генерирует корректный синтаксис plpgsql, но не забудьте проверить права доступа и логику на тестовой базе.

Промт 7. Генерация тестовых данных

Задача: Создать набор данных для проверки.

Промт:

Сгенерируй SQL-скрипт на PostgreSQL для вставки 100 тестовых записей в таблицу employees (id serial, name text, department text, salary numeric). Используй random() и array для разнообразия.

Пример результата:

INSERT INTO employees (name, department, salary)
SELECT 
    'Employee ' || i,
    (ARRAY['IT', 'HR', 'Sales', 'Marketing'])[floor(random() * 4 + 1)],
    round((random() * 5000 + 3000)::numeric, 2)
FROM generate_series(1, 100) AS i;

Удобство: Быстрое наполнение базы для тестирования — экономит часы ручной работы.

Экспертные промты: для сложных сценариев

Промт 8. Анализ плана выполнения

Задача: Найти узкое место в запросе.

Промт:

Вот план выполнения запроса из PostgreSQL (EXPLAIN ANALYZE). Проанализируй его, найди проблемные места и предложи, как ускорить запрос. План:

Seq Scan on orders (cost=0.00..1500.00 rows=50000 width=24)
  Filter: (customer_id = 12345)

Пример результата:

План показывает Seq Scan (последовательное сканирование) — это означает, что PostgreSQL читает всю таблицу, что очень медленно при большом объёме. Рекомендую создать индекс по customer_id, тогда оптимизатор сможет использовать Index Scan.

Практика: Этот промт помогает быстро выявлять причины тормозов и принимать меры.

Промт 9. Миграция данных между схемами

Задача: Перенести данные с преобразованием типов.

Промт:

Напиши SQL-запрос на PostgreSQL для копирования данных из таблицы old_schema.users в new_schema.users. При этом поле is_active (boolean) должно преобразоваться в строку 'active'/'inactive'. Игнорируй пользователей без email.

Пример результата:

INSERT INTO new_schema.users (user_id, name, email, status)
SELECT 
    user_id,
    name,
    email,
    CASE WHEN is_active THEN 'active' ELSE 'inactive' END
FROM old_schema.users
WHERE email IS NOT NULL;

Безопасность: Используйте транзакции, чтобы избежать частичного переноса.

Промт 10. Написание триггера

Задача: Автоматически обновлять поле updated_at.

Промт:

Создай триггер на PostgreSQL, который автоматически обновляет поле updated_at при изменении строки в таблице products. Напиши функцию и триггер.

Пример результата:

CREATE OR REPLACE FUNCTION update_updated_at()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = NOW();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER products_updated_at
BEFORE UPDATE ON products
FOR EACH ROW
EXECUTE FUNCTION update_updated_at();

Реальный кейс: Я использовал такой триггер для аудита изменений в справочниках.

Промт 11. Работа с JSONB

Задача: Извлечь данные из JSON-поля.

Промт:

Напиши SQL-запрос на PostgreSQL для извлечения из таблицы events (event_data jsonb) всех событий типа 'click', у которых в поле 'page' значение 'home'. Выведи количество таких событий за сегодня.

Пример результата:

SELECT COUNT(*)
FROM events
WHERE event_data->>'type' = 'click'
  AND event_data->>'page' = 'home'
  AND created_at::date = CURRENT_DATE;

Продвинутость: JSONB — мощная возможность PostgreSQL, и модель отлично с ней справляется.

Промт 12. Построение отчёта с GROUPING SETS

Задача: Создать сводный отчёт по нескольким уровням группировки.

Промт:

Напиши SQL-запрос на PostgreSQL, который выводит сумму продаж по категориям и по подкатегориям, а также общий итог. Используй GROUPING SETS. Таблица sales (category text, subcategory text, amount numeric).

Пример результата:

SELECT 
    category,
    subcategory,
    SUM(amount) AS total_sales
FROM sales
GROUP BY GROUPING SETS (
    (category, subcategory),
    (category),
    ()
)
ORDER BY category, subcategory NULLS LAST;

Эффективность: Один запрос вместо трёх — экономия времени и ресурсов.

Как я использовал эти промты: реальный кейс

В нашем проекте была задача: выгрузить отчёт по активности пользователей за полугодие. Раньше я писал запрос вручную, тратил около часа. С помощью промта 1 я получил рабочий запрос за 5 минут. Затем промт 4 помог оптимизировать его: добавил индекс на дату, и время выполнения упало с 30 секунд до 0.5 секунды. В итоге весь процесс занял 15 минут вместо двух часов. Таких примеров у меня накопилось много — именно поэтому я решил поделиться этими промтами.

Заключение

Большие языковые модели — это не замена аналитику, а мощный инструмент, который ускоряет рутинные задачи. Промты, которые я привёл, покрывают 90% ежедневных потребностей аналитика: от простых SELECT до сложных оптимизаций. Главное — уметь грамотно формулировать задачу и проверять результат. Начните с базовых промтов, постепенно переходите к продвинутым — и вы заметите, как много времени освобождается для действительно важных задач.

Попробуйте применить хотя бы один из этих промтов в своей работе. Уверен, вы удивитесь результату. А если у вас есть свои любимые промты для SQL — делитесь в комментариях!