Как составить SQL-запрос с помощью ИИ на учебных данных

Привет, я Гриша. Нейросеть может перевести вопрос на обычном языке в черновик SQL, но для этого ей нужны названия таблиц, связь между ними и точный смысл результата. Начинайте на учебных данных, потому что запрос может вернуть не те строки или повлиять на таблицу, если содержит изменение данных. Разберём безопасную последовательность для чтения.

Опишите схему и вопрос

Укажите имена таблиц, столбцов, типы данных и связи. Например: orders содержит order_id, customer_id, created_at, amount; customers — customer_id и region. Если модель не знает схему, она придумает поля вроде total_price или status, которых в базе нет.

Сформулируйте желаемый результат: «посчитать количество заказов по регионам за март» или «показать товары без категории». Определите временную зону, включённость границ периода, обработку пустых значений и нужен ли один результат на клиента или на строку заказа.

Не отправляйте реальные таблицы с именами, адресами, платежами или токенами. Для черновика достаточно вымышленной схемы и пары тестовых строк.

Попросите объяснить запрос

Попросите модель создать только запрос чтения и пояснить каждую часть: источник, соединение, фильтр, группировка и сортировка. Укажите конкретную СУБД, если она важна, потому что функции дат и синтаксис могут различаться. Не просите запускать результат на производственных данных без ревью.

Вместо «напиши запрос к моей базе» сформулируйте: «по этой учебной схеме подготовь SELECT, который возвращает число заказов по регионам за март 2026 года. Используй границы периода от начала марта включительно до начала апреля не включая; объясни, какие столбцы группируются. Не придумывай поля и не изменяй данные». Запрос чтения снижает риск, но всё равно требует проверки.

Пример: продажи по регионам

Учебная таблица orders: order_id, customer_id, created_at, amount. Таблица customers: customer_id, region. Хотим сумму заказов за март по регионам. Концептуально запрос выбирает регион и сумму amount, соединяет таблицы по customer_id, фильтрует created_at по нужному интервалу и группирует по region. В SQL это оформляется как SELECT с JOIN, WHERE и GROUP BY, но названия функций и запись дат проверьте для вашей СУБД.

Тестовые данные: клиент из «Север» сделал заказ 100 в марте; тот же регион — заказ 50; «Юг» — заказ 70; в апреле «Север» — заказ 200. Ожидаемый результат: «Север — 150», «Юг — 70». Если модель возвращает 350 для Севера, она включила апрель; если 100 — потеряла второй мартовский заказ.

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

Тестируйте на копии

Начните с небольшой учебной таблицы и сравните ответ вручную. Если запрос нужен к рабочей системе, сначала используйте только режим чтения и ограниченный период. Посмотрите, сколько строк он может вернуть, есть ли дубликаты и совпадают ли итоговые суммы с независимым расчётом.

Не запускайте неизвестные UPDATE, DELETE, DROP или другие команды изменения данных. Если задача требует изменения, получите ревью от человека, который отвечает за базу, используйте транзакцию и резервную копию по процессу команды. Модель может не заметить побочный эффект.

Частые ошибки

Запрос может соединять таблицы по неверному ключу, использовать локальную дату вместо UTC, удваивать строки или считать NULL как ноль. Попросите модель назвать эти риски и предложить контрольные запросы. Сверьте столбцы со схемой базы, а не с предположением.

Сохраняйте вопрос, схему, SQL и ожидаемые примеры вместе. Если схема меняется, старый запрос может стать неправильным. Для сложной аналитики попросите коллегу проверить логику и план выполнения.

Сверьте запрос с исходными строками

Для учебного примера составьте ожидаемый ответ вручную до выполнения запроса. Если нужно посчитать покупки по категории, выпишите несколько строк и отметьте, какие должны попасть в результат. Проверьте, не исключает ли условие запись на границе даты и не учитывает ли пустое значение как ноль. Затем сравните количество найденных строк с простым просмотром исходной таблицы.

Особое внимание уделите соединению таблиц. Одна покупка может иметь несколько связанных позиций, поэтому после соединения число строк иногда растёт. Попросите модель объяснить ключ связи и покажите маленький пример до и после соединения. Если итоговая сумма удвоилась, вероятно, агрегация выполняется на другом уровне детализации. В учебной базе можно исследовать такие ошибки, не затрагивая рабочие данные. Для дальнейшей практики сохраняйте запрос вместе с описанием схемы и ожидаемым результатом — тогда его проще перечитать и адаптировать к новой задаче.

Частые вопросы