Коды для Gemini и не только: SQL-отчёт по месяцам за один запрос
Коды для Gemini ищут, чтобы получить готовый запрос к базе без аналитика. Это статья LibraChat: SQL-отчёт по выручке, заказам и среднему чеку за 2026 год с разбором.
Денис
Продакт LibraChat
8 мин чтения
Двенадцать месяцев, четыре показателя, одна таблица: выручка, число заказов, средний чек и уникальные покупатели за каждый месяц 2026 года. Такой отчёт я получил одним SQL-запросом, который написала нейросеть. Запрос «коды для gemini» обычно набирают, когда нужен готовый код под задачу, а аналитика рядом нет. Я продакт в LibraChat, поэтому запрос отправлял туда, и статья тоже из нашего блога. Gemini — семейство моделей Google, о нём речи дальше не будет. Ниже запрос, ответ, разбор каждой строки и одна ловушка с часовым поясом, о которой стоит знать до того, как показывать цифры руководству.
Коды для Gemini ищут и продакты: зачем SQL, если есть дашборды
Дашборды хороши, пока вопрос совпадает с тем, что в них заложили. Мне понадобилась простая вещь для небольшого магазина, которому я помогаю с продуктом: помесячная картина за год. Причём с месяцами, в которых заказов не было вовсе. Дашборд такие месяцы просто не показывал, и на графике получался ровный рост, которого не было.
У магазина обычная база PostgreSQL. Таблица заказов `orders` с четырьмя колонками: номер, покупатель, дата создания, сумма. Писать запросы я умею на уровне «посчитать строки». Отчёт с пустыми месяцами и уникальными покупателями — это уже задача, на которую я потратил бы вечер с документацией.
Запрос, который я отправил
Напиши SQL-запрос для PostgreSQL. Есть таблица orders с колонками id, customer_id, created_at, total. Нужно по каждому месяцу 2026 года: выручка, число заказов, средний чек и число уникальных покупателей. Объясни каждую строку запроса.
На результат здесь работают три детали:
названа база, потому что функции для дат в разных базах отличаются;
перечислены колонки, и нейросеть не гадает, как они называются;
есть просьба объяснить каждую строку, без неё я не смог бы проверить, правильно ли посчитано.
Что пришло: запрос с пустыми месяцами
Первая строка ответа сразу ответила на мою главную боль:
По каждому месяцу 2026 года, включая месяцы без заказов.
Я об этом не просил прямо. Но нейросеть сама построила запрос так, чтобы пустые месяцы не пропали. Сначала создаётся ряд из двенадцати дат, от 1 января до 1 декабря, а уже к нему присоединяются заказы. Если в каком-то месяце заказов нет, строка всё равно остаётся, а в ней нули.
Вот ключевая часть:
```sql
SELECT
m.month_start AS month,
COALESCE(SUM(o.total), 0) AS revenue,
COUNT(o.id) AS orders_count,
COALESCE(AVG(o.total), 0) AS avg_check,
COUNT(DISTINCT o.customer_id) AS unique_customers
FROM months m
LEFT JOIN orders o
ON o.created_at >= m.month_start
AND o.created_at < m.month_start + INTERVAL '1 month'
```
Разбор каждой строки, ради которого ищут коды для Gemini
В ответе каждая строка объяснена. Я свёл главное в таблицу, своими словами:
Строка · Что делает
`generate_series(...)` — ряд из 12 дат: первое число каждого месяца
`COALESCE(SUM(o.total), 0)` — выручка; если заказов нет, 0, а не пусто
`COUNT(o.id)` — число заказов; пустой месяц даёт 0, а не 1
`COALESCE(AVG(o.total), 0)` — средний чек; без заказов 0
`COUNT(DISTINCT o.customer_id)` — сколько разных покупателей в месяце
`LEFT JOIN orders` — месяц без заказов остаётся в отчёте
условие с `<` следующего месяца — границы месяцев не пересекаются
Третья строка — тонкость, на которой я сам бы споткнулся. Если считать `COUNT(*)`, пустой месяц после присоединения дал бы единицу: строка-то есть. А `COUNT(o.id)` считает только настоящие заказы. В ответе это сказано прямо, и мне не пришлось узнавать это на собственной ошибке.
Ловушка с часовым поясом
Последний абзац ответа был не про синтаксис, а про цифры, которые увидит руководитель:
Если created_at имеет тип timestamptz, границы лучше задавать с часовым поясом, например TIMESTAMPTZ '2026-01-01 Europe/Moscow', иначе месяц может сдвинуться относительно московского времени.
Я проверил тип колонки. Так и есть, время хранится с поясом. Сервер считает время по UTC, а это на три часа раньше московского. Без поправки заказы, сделанные в первые часы нового месяца по Москве, попали бы в предыдущий месяц. На годовом отчёте это мелочь. А на отчёте за конкретный месяц, где сравнивают план и факт, это может быть разница в несколько процентов.
Я поменял границы на московское время и прогнал запрос ещё раз. Октябрь потерял 2 заказа, а ноябрь их получил. Ровно как предупреждал ответ.
Как я проверяю SQL-отчёт, прежде чем показывать
Сначала я доверял запросам на слово. Однажды я столкнулся с тем, что отчёт показывал выручку вдвое больше реальной: в таблице были и заказы, и их возвраты, а запрос складывал всё подряд. С тех пор у меня короткий порядок проверки, на него уходит 10 минут:
Беру один месяц, цифры по которому знаю из бухгалтерии, и сравниваю.
Считаю число заказов за этот месяц простым запросом без присоединений и сверяю с отчётом.
Смотрю на месяц без заказов: там должны быть нули, а не пустота и не единица.
Проверяю тип колонки с датой и часовой пояс сервера.
Смотрю, нет ли в таблице отменённых заказов или возвратов, которые надо исключить.
Пятый пункт в этом запросе не учтён, потому что я о нём не сказал. В нашей таблице статусов не было, и он не понадобился. Но если у тебя есть колонка статуса, допиши в запрос, какие заказы считать.
Что я бы добавил в запрос в следующий раз
Первая версия запроса была хорошей, но после проверки я понял, чего в ней не хватало. Если бы я писал её сейчас, я бы сразу добавил три строки.
Тип колонки с датой и часовой пояс, в котором живёт бизнес. Тогда границы месяцев сразу будут по Москве, и не придётся переделывать.
Какие заказы считать. Оплаченные, доставленные, все подряд. Для выручки это разные цифры, и выбирать должен человек, который знает, что считается продажей в этом магазине.
Формат результата. Мне удобнее, когда месяц выводится не датой «2026-03-01», а коротким названием, и когда суммы округлены до рубля. Это мелочь, но отчёт уходит людям, которые не работают с базой.
Я попробовал так и сделал вторую версию для соседнего проекта: те же четыре показателя, но с этими тремя строками в запросе. Переделывать после проверки ничего не пришлось. Чем больше я знаю о своих данных до запроса, тем меньше работы после.
Что показал отчёт
Отчёт я выгрузил в таблицу и положил рядом с дашбордом. Разница была в двух месяцах. В феврале у магазина были технические работы и почти не было заказов, а в июле владелица была в отпуске и закрыла приём. На дашборде эти месяцы просто исчезали, и рост выглядел плавным. В отчёте видно провалы, и видно, как быстро магазин после них восстанавливался.
Средний чек тоже рассказал своё. В месяцы после провалов он был выше обычного: возвращались постоянные покупатели с крупными заказами. Это стало темой для следующего разговора с владелицей о программе лояльности. Без отчёта с пустыми месяцами мы бы этого не увидели: на сглаженном графике постоянные покупатели теряются среди новых.
Где коды для Gemini или любой другой нейросети не заменят тебя
Запрос написан под мою таблицу. Если колонки называются иначе, его надо поправить. Если сумма хранится в копейках, выручку надо поделить на сто. Об этом запрос должен сказать сам.
И главное. SQL отвечает на вопрос, который ты задал. «Выручка по месяцам» — понятный вопрос. «Почему упали продажи» — нет, на него отвечает человек, который смотрит на цифры и знает контекст: отпуск, технические работы, акции. Отчёт даёт материал для разговора, а не вывод.
Опиши свою таблицу так же, как я: база, колонки, какие показатели и за какой период. Добавь «объясни каждую строку». Отправь в чат LibraChat и проверь тип колонки с датой, прежде чем показывать отчёт. Попробуй сначала на одном месяце, где цифры знаешь наизусть. Если совпадёт, запускай на весь год. Если таких отчётов понадобится много, сравни тарифы LibraChat.
коды для geminisqlpostgresqlотчёт по месяцампродуктовая аналитикаинтернет-магазин
