Нейросеть умеет предложить правдоподобный SQL даже для несуществующих колонок. Поэтому качество запроса зависит от контекста: схемы, бизнес-определений и примеров ожидаемого результата. Практический процесс строится вокруг проверяемого вопроса к данным. Сначала определяют, что нужно посчитать, затем подтверждают связи таблиц и только после этого выполняют запрос с ограниченными правами.
Что передать вместо полной базы
Подготовьте названия таблиц и колонок, типы данных, первичные и внешние ключи, ограничения уникальности и используемый диалект SQL. Для денежных полей укажите валюту и единицу хранения. Для дат уточните часовой пояс. Несколько синтетических строк помогут показать случаи, которые схема сама по себе не объясняет.
Опишите единицу результата: одна строка на клиента, заказ, день или товар. Именно здесь часто появляется ошибка агрегации. Если у заказа несколько позиций и несколько платежей, прямое соединение обеих дочерних таблиц может перемножить записи. Модель должна объяснить ожидаемую кратность каждого JOIN до написания итогового SUM.
Последовательность работы
- Сформулируйте вопрос без SQL: например, сумма оплаченных заказов по клиентам за заданный календарный месяц.
- Зафиксируйте правила для возвратов, отмен, пустых значений и клиентов без заказов.
- Попросите план запроса и объяснение каждой связи. Проверьте его по схеме.
- Получите параметризованный SELECT. Значения пользователя не должны склеиваться с текстом SQL.
- Выполните запрос на небольшой тестовой базе или безопасной копии с учётной записью только для чтения.
- Проверьте план выполнения и ограничения ресурсов, прежде чем запускать расчёт на полном объёме.
Пример ошибки, которую легко пропустить
Учебный заказ содержит две позиции на 400 и 600 рублей и два платежа на 500 рублей. Если соединить позиции с платежами только по order_id, получится четыре строки. Сумма позиций станет 2 000 вместо 1 000 рублей. Числа здесь иллюстративные. Исправление обычно требует предварительно агрегировать каждую дочернюю таблицу до уровня заказа или выбрать только необходимый источник суммы.
Проверяйте не только итог, но и промежуточную таблицу после соединения. Попросите модель показать количество строк до JOIN и после него, а также количество уникальных заказов. Такая проверка быстрее обнаруживает размножение записей, чем чтение длинного объяснения о том, почему запрос якобы корректен.
Промпт
Диалект: PostgreSQL. Ниже схема и бизнес-правила. Нужен только SELECT с параметрами периода. Сначала объясни уровень каждой таблицы и кратность JOIN. Не придумывай колонок. Выведи запрос, ожидаемый формат результата и тестовые данные для случаев: нет заказов, два платежа, возврат, NULL. Не выполняй запрос. Отдельно укажи риск размножения строк и способ проверки контрольной суммы.План выполнения и права
В документации PostgreSQL по EXPLAIN важно различие между просмотром плана и EXPLAIN ANALYZE: вариант ANALYZE действительно выполняет запрос. Не используйте его как безусловно безопасную предварительную проверку неизвестной команды. Права только для чтения и тестовая среда остаются отдельными мерами контроля.
Ограничение числа возвращённых строк не гарантирует небольшую стоимость вычисления: сортировка или агрегация может затронуть большой объём до LIMIT. Обсудите с администратором лимит времени, допустимое окно запуска и использование реплики. ИИ может помочь прочитать план, но выводы об индексах нужно соотнести с реальным распределением данных и нагрузкой.
Приёмка запроса
Подготовьте маленький набор данных, результат которого считается вручную. Включите граничные даты: начало периода, последнее мгновение перед его окончанием и запись сразу после. Для временных интервалов удобно заранее договориться о включённой нижней и исключённой верхней границе. Сохраните SQL вместе с бизнес-описанием, иначе позже правильный запрос могут применить к другому вопросу.
Частые вопросы
Можно ли дать модели только названия таблиц?
Для чернового обсуждения да, но окончательный запрос требует типов, ключей и значений статусов. Иначе модель заполнит пробелы предположениями.
Нужно ли запрещать все подзапросы?
Нет. Важнее понятная логика и измеренный план. Упрощение синтаксиса само по себе не делает запрос правильным или быстрым.
Когда допустим UPDATE?
Это отдельная задача изменения данных с резервной копией, ограничением области, транзакцией и проверкой результата. Не расширяйте запрос аналитики до исправления базы незаметно.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.