Описываете структуру таблиц и спрашиваете по-русски, что нужно узнать — Kimi пишет SQL-запрос, объясняет его по шагам и предупреждает о подводных камнях. Получаешь запрос и понимание, как он работает.
Переведи мой вопрос на человеческом языке в SQL-запрос — и покажи, где запрос может обмануть.
База и версия: [СУБД: PostgreSQL 16]
Таблицы (только те, что нужны): [СХЕМА: orders(id, client_id, created_at, amount, status),
clients(id, name, city, created_at), order_items(order_id, product_id, qty, price)]
Что нужно узнать: [ВОПРОС: выручка по месяцам за прошлый год с разбивкой по городам, только
оплаченные заказы]
Особенности данных: [ОСОБЕННОСТИ: status бывает paid, cancelled, pending; у части заказов amount
пустой, сумму тогда надо считать из order_items; даты в UTC, отчётность в московском времени]
Что нужно:
1. Сначала перескажи задачу своими словами одним абзацем — чтобы я подтвердил, что ты понял так же.
2. Запрос с комментариями к каждому блоку.
3. Где этот запрос может дать неверный результат: дубли после join, потеря строк из-за inner join,
NULL в суммах, границы месяцев при переводе часового пояса.
4. Запрос-проверка: чем сверить итог, чтобы поймать ошибку (например, общая сумма без группировки).
5. Если из схемы задачу решить нельзя — скажи, какого поля не хватает, вместо того чтобы выдумывать.
Отсечка. Не бери amount, если в особенностях сказано, что он бывает пустым, — либо coalesce
из order_items, либо явно скажи, что строки потеряются. Не пиши `SELECT *` в финальном запросе.
Не игнорируй часовые пояса, если они упомянуты: январь в UTC и в Москве заканчивается в разное время.
Не добавляй в запрос таблицы, которых нет в схеме.
Проверка перед выдачей: посчитай мысленно, что вернёт запрос для клиента с двумя оплаченными
заказами в одном месяце, один из которых с пустым amount. Если такой клиент выпадает из выборки —
исправляй.
Собрать под себя — поля заполнены рабочими значениями, меняйте их и промпт выше обновится сам
Пример: PostgreSQL, таблицы orders(id, user_id, amount, status, created_at) и users(id, segment). Вопрос: «средний чек по сегментам за последние 90 дней, только оплаченные». Kimi пересказывает: «считаю AVG(amount) с группировкой по segment, фильтр status='paid' и created_at >= now() - interval '90 days'» — вы подтверждаете. Запрос с комментариями, плюс предупреждение: «если заказ без пользователя, inner join его выкинет — нужен left join?». Проверка: сравнить сумму по сегментам с общей выручкой за период. Совет 1: давайте реальные имена колонок и примеры значений status — «paid» или «оплачен» решает всё. Совет 2: Kimi не видит ваши данные и не выполнит запрос — тестируйте с LIMIT 100 сначала. Совет 3: для ClickHouse и диалектов прямо пишите СУБД — синтаксис оконных функций и дат сильно различается.
