В отчёте нужна выручка по клиентам за месяц, но в базе несколько таблиц и непонятно, как связать их без двойного счёта. Промпты для SQL-запросов помогут получить черновик SELECT или объяснить уже написанный запрос. Чат работает с переданной схемой и примерами; выполнить запрос и сверить результат нужно в своей среде.
Промпты для SQL-запросов: с чего начать
Выберите одну задачу: написать запрос, разобрать существующий SQL или найти причину расхождения в результате. Для генерации нужны схема и правило расчёта. Для объяснения — сам запрос и смысл полей. Для диагностики — ещё небольшой пример данных и ожидаемые строки.
SQL — язык работы с данными в базе. Запрос SELECT выбирает строки и вычисляет результат; сам по себе текст такого запроса ещё не говорит, верно ли посчитан бизнес-показатель. Например, «продажи за октябрь» могут означать оплаченные заказы, отгруженные товары или выручку после возвратов. Эти правила задаёт человек.
| Задача | Что подготовить | Что запросить у модели |
|---|---|---|
| Создать SELECT | Схему, связи, период, показатель | Один запрос, допущения и объяснение |
| Объяснить SQL | Запрос, смысл полей и таблиц | Результат каждого блока и места риска |
| Найти расхождение | SQL, несколько строк, ожидаемый итог | Гипотезы и проверки, различающие их |
| Разобрать производительность | Запрос и обезличенный план из своей базы | Объяснение плана, без обещания ускорения |
В Agent Roi каждый запрос получает отдельный ответ по доступным материалам. Модель не подключается к базе, не видит остальные таблицы и не проверяет запрос на реальных данных. Начинайте с одного отчёта, который можно пересчитать на маленьком примере.
Что передать в чат
Соберите короткую карточку задачи. Укажите систему базы и версию: PostgreSQL, MySQL, SQL Server или другую. Диалект — это вариант SQL с конкретными функциями и синтаксисом. Запрос с обработкой дат для одной системы может потребовать изменения в другой.
База и версия: [название и версия].
Задача: [какое решение нужен результат].
Таблицы: [имена, нужные поля, типы].
Ключи и связи: [что уникально; один ко многим или иначе].
Показатель: [точное правило расчёта].
Фильтры: [статус, период, часовой пояс, исключения].
Результат: [столбцы, одна строка на что, сортировка].
Пример входа и ожидаемого выхода: [малый набор].
Разрешено: только SELECT по указанным таблицам.«Одна строка на что» задаёт детализацию результата: на заказ, клиента или месяц. Если нужен итог по клиенту, а в ответе несколько строк на каждую позицию заказа, запрос решает другую задачу. Отдельно укажите валюту, возвраты, отмены и смысл даты.
Покажите структуру нужных таблиц и несколько вымышленных либо обезличенных строк. Реальную выгрузку всей базы передавать не требуется. Пароли, строки подключения и персональные сведения не помогают описать расчёт. Связи и типы сохраняйте: иначе обезличивание уничтожит условия проверки.
Готовые промпты для создания и объяснения SQL
Создать запрос по описанию
Подготовь один SELECT для [база, версия] по карточке ниже.
Используй только перечисленные таблицы и поля.
Не подключайся к базе и не утверждай, что запрос выполнен.
Сначала перечисли существенные пробелы. Если без них нельзя
однозначно посчитать показатель, верни вопросы вместо SQL.
Если данных достаточно, верни:
1. Допущения и детализацию результата.
2. Запрос в одном блоке кода.
3. Объяснение фильтров, связей и агрегирования.
4. Тестовые случаи и ожидаемые строки.
Не добавляй команды записи или изменения структуры.
Карточка задачи: [вставьте данные].Просьба «только SELECT» ограничивает желаемый ответ, но не создаёт права доступа в базе. Выполняйте код под подходящей учётной записью и проверяйте вызываемые функции: название SELECT не гарантирует отсутствие любых побочных действий.
Объяснить существующий SQL
Объясни запрос ниже для [база, версия]. Анализируй только
переданный SQL и описание схемы; внешние объекты неизвестны.
Опиши исходные строки, условия отбора, JOIN, группировку
и итоговую детализацию. Покажи, где возможны дубли или NULL.
Для каждого риска приведи маленький пример.
Не переписывай запрос до объяснения и не объявляй его верным.
SQL: [запрос].
Схема и смысл полей: [описание].
Бизнес-правило: [ожидаемый расчёт].Такой разбор полезен перед изменением чужого отчёта. Попросите отдельно назвать неизвестные условия: модель может объяснить функцию по названию неверно, если её определение не передано.
Найти причину неверной суммы
В запросе есть расхождение: ожидалось [результат], получено
[результат]. Вот SQL, схема и небольшой пример данных.
Раздели выводы на доказуемые по примеру и гипотезы.
Для каждой гипотезы дай отдельную проверку только для чтения
и объясни, какой её результат подтвердит или опровергнет причину.
Предложи минимальную правку только для подтверждаемого случая.
Не используй DISTINCT как универсальное исправление дублей.DISTINCT удаляет одинаковые строки результата. Он не заменяет правильное правило расчёта: две разные покупки на одинаковую сумму могут быть законными данными.
Пример первого сообщения и ожидаемого ответа
Возьмём учебный набор, не данные реального клиента. Нужно посчитать оплаченные заказы за октябрь; каждый заказ уже содержит итоговую сумму в рублях. Возвратов нет, paid_date имеет тип date, а order_id уникален.
| order_id | customer_id | paid_date | status | amount |
|---|---|---|---|---|
| 101 | 7 | 2026-10-03 | paid | 1200 |
| 102 | 7 | 2026-10-18 | paid | 800 |
| 103 | 9 | 2026-10-20 | cancelled | 500 |
| 104 | 9 | 2026-10-31 | paid | 700 |
| 105 | 7 | 2026-11-01 | paid | 900 |
Первое сообщение после шаблона:
PostgreSQL. Таблица orders: order_id integer PRIMARY KEY,
customer_id integer NOT NULL, paid_date date, status text,
amount numeric NOT NULL. Каждый заказ — одна строка.
Нужна одна строка на клиента с числом и суммой оплаченных
заказов за октябрь 2026. Период — по paid_date.
Исключить другие статусы. Сортировка по customer_id.
Ожидаю: клиент 7 — 2 заказа и 2000; клиент 9 — 1 и 700.Пример ожидаемого черновика:
SELECT customer_id,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM orders
WHERE status = 'paid'
AND paid_date >= DATE '2026-10-01'
AND paid_date < DATE '2026-11-01'
GROUP BY customer_id
ORDER BY customer_id;Этот текст приведён для разбора логики; чат его не выполнил. Проверьте ожидаемые строки в своей тестовой базе. Если paid_date на самом деле хранит время с часовым поясом, исходная карточка меняется: прежде нужно определить календарные границы отчёта.
Как проверить строки, суммы и JOIN
JOIN соединяет строки таблиц. Если один заказ связан с тремя товарными позициями, после такого соединения его итоговая сумма может встретиться три раза. Перед суммированием выясните, считаете вы позиции или заказы. В документации PostgreSQL о соединениях показано, как условия JOIN и фильтры влияют на результат; в частности, перенос условия из ON в WHERE меняет поведение внешнего соединения.
Проверьте отдельные случаи:
- Один заказ с двумя позициями: итог заказа учитывается один раз.
- Клиент без заказа: он включён или исключён по вашему правилу.
- Пустое значение NULL: модель не подменила неизвестную сумму нулём без условия.
- Заказ на границе месяца: период включает только нужные даты.
- Отмена и возврат: обработаны по указанному бизнес-правилу.
- Пустой набор: формат результата согласован, отсутствие строки не скрывает ошибку фильтра.
Сверка на маленьком наборе проверяет смысл расчёта. Проверка на рабочем объёме отдельно оценивает время и нагрузку.
EXPLAIN показывает план выполнения, но не доказывает правильность показателя. В PostgreSQL EXPLAIN ANALYZE действительно выполняет запрос. Не запускайте его как безусловно безопасный просмотр: согласуйте среду, доступ и нагрузку с ответственным за базу.
Что делать с ошибкой и большим контекстом
Верните в чат полный текст ошибки, диалект и версию, текущий запрос и относящийся к нему кусок схемы. Добавьте результат конкретного теста: «на клиенте 7 ожидал 2000, получил 4000». Это точнее просьбы «проверь ещё раз».
Контекстное окно ограничивает материалы, которые модель может учитывать в одном ответе. Его расходуют история диалога, инструкции и входные данные; большие вложения могут превысить доступный объём. Подготовьте одну самодостаточную карточку и оставьте место для объяснения. При переходе в новый диалог снова передайте правила и текущую версию запроса. Загрузка схемы частями не гарантирует, что все прежние части доступны модели.
FAQ
Можно ли попросить чат проверить всю базу?
Для обычного чата нужен ограниченный набор схемы и примеров. Аудит всей базы требует доступа к объектам, данным, правам и реальным планам; этот промпт такого доступа не даёт.
Можно ли использовать запрос сразу в отчёте?
Сначала проверьте его на тестовых данных, затем сверяйте итог с независимым расчётом. Показатель, который выглядит правдоподобно, может содержать ошибку в статусе или детализации.
С чего начать в Agent Roi
Выберите один отчёт, подготовьте обезличенную схему и несколько строк с ожидаемым итогом. Передайте их в чат Agent Roi с шаблоном создания SELECT. Сохраните ответ как черновик и выполните проверку в своей базе; исправленные условия станут вашим повторно используемым промптом.
Связанные материалы
- ИИ для аналитиков — как связать расчёт с рабочим вопросом.
- Промпты для формул Excel — проверка небольшого расчёта в таблице.
- Как писать промпты для ИИ — задача, вход и формат ответа.
Больше материалов по теме — в разделе «Промпты».
