SQL-проверки

Цель: Получить корректные SQL-запросы для проверки данных после сценария (проверка записей в БД, подсчёт, целостность). Используйте низкую температуру (0–0.1) для минимизации синтаксических ошибок.

⏱ Время: 10–15 минут на описание схемы/сценария и прогон + 5–10 минут на проверку запроса в тестовой БД.

SQL для проверки состояния БД

RTCCO

7.11 — пост-условия и верификация данных

sqlбаза данныхпроверка данных

Ты — QA-инженер с опытом в SQL. Сгенерируй только SQL-запросы для проверки данных.

Контекст СУБД: PostgreSQL 16.2
Особенности синтаксиса: CTE (WITH), RETURNING, gen_random_uuid()
Схема (обезличенная): promo_codes, orders, promo_applications — только поля из требований

Задача: После выполнения сценария [кратко опиши сценарий] нужно проверить:
- [Что проверить 1, например: в таблице orders появилась запись с order_id = X и status = 'paid']
- [Что проверить 2, например: количество записей в order_items для этого заказа]

Схема (если известна): [названия таблиц и ключевых полей]

Ограничения:
- Только валидный SQL, без пояснений в середине запроса.
- Не выдумывай таблицы и поля, которых нет в схеме; если чего-то не хватает — напиши: "Требуется уточнение: [что]".
- Формат вывода: один запрос на пункт проверки, с комментарием в одной строке перед запросом.

Частые ошибки применения шаблона

SQL под другую СУБД (MySQL-синтаксис при PostgreSQL).
Таблицы и поля выдуманы — нет схемы или обезличенного описания.
Запрос выполняют на production без ревью и без тестовой среды.

Всегда проверяй сгенерированный SQL на тестовой БД и подставь реальную схему — LLM может ошибаться в названиях полей и диалекте.