Девять запросов: 71 оплаченный заказ без платежа и 53 расхождения в суммах

Пять таблиц, 9675 строк, девять проверок целостности — с запросами и числами.

Что это

Агент ищет дефект в данных, а не только в интерфейсе

Половина «странных» дефектов объясняется данными: заказ оплачен, платежа нет; сумма в чеке не равна сумме строк. Агент пишет запросы, которые это показывают, и приносит число — не «где-то расходится», а «71 заказ из 1714 оплаченных без платежа».

Вход и выход

Что проверено запросами, а что подключим

Вход

База магазина: пользователи, заказы, платежи, строки заказа, события. 9675 строк в пяти таблицах.

  • Запросы — выполнены

    Девять проверок целостности: JOIN, LEFT JOIN, GROUP BY, сравнение сумм. Данные кейса собраны искусственно.

  • Находки — посчитаны

    71 оплаченный заказ без платежа, 53 расхождения суммы, 3 платежа по неоплаченному, 22 заказа удалённого пользователя.

  • Ложные тревоги — отсеяны

    Дублей платежа нет, заказов без пользователя нет, заказов в будущем нет — три проверки дали ноль.

  • Боевая база — подключим

    Postgres Pro или ЛИНТЕР: роль только на SELECT и адрес стенда, один день.

Что открывается: запросы, находки и что это значит

Данные кейса сконструированы; запросы, СУБД и правила проверки — настоящие

  1. 1

    Девять запросов

    Название проверки, SQL, результат: сколько строк и что это значит для дефекта.

  2. 2

    Находки по целостности

    Четыре проверки нашли расхождения, три дали ноль, две — справочные.

  3. 3

    Вывод и что делать

    Где ошибка пишется кодом, где данные уже испорчены, и что проверить в первую очередь.

Файлы

Что агент делает и что остаётся человеку

Пишет запросАгент: JOIN, GROUP BY, сравнение сумм — под конкретную гипотезу дефекта. Человек: говорит, что именно болит.
Считает находкиАгент: число строк и долю от общего. Человек: решает, что из этого дефект.
Отделяет ложныеАгент: проверки, которые дали ноль, тоже в отчёте — это доказательство, а не пустота.
Ищет причинуАгент: где запись появляется — код или миграция. Человек: исправляет и решает про данные.
Проверяет послеАгент: повторяет те же запросы после исправления. Человек: подтверждает, что данные чистые.

Сценарий: от жалобы до запроса

  1. 1

    Гипотеза

    Из дефекта: «оплатил, а статус не тот» — значит проверяем связку заказ-платёж.

  2. 2

    Схема

    Агент читает структуру: ключи, связи, обязательные поля.

  3. 3

    Запрос

    LEFT JOIN ищет отсутствующее, сравнение сумм — расхождение, GROUP BY — дубли.

  4. 4

    Число

    Сколько строк затронуто и какая это доля — иначе находка не измерена.

  5. 5

    Причина

    Где запись появляется: код, миграция или ручная правка.

  6. 6

    Выход

    Запросы и находки файлами; повторный прогон после исправления.

Откуда данные

Что нужно на входе

  • Схема базы

    Таблицы и связи: без них запрос пишется наугад.

  • Тестовый контур

    Копия базы или стенд: на боевой агент ходит только на чтение и по разрешению.

  • Правила

    Что считается целым: сумма заказа равна сумме строк, оплаченный заказ имеет платёж.

  • Выгрузка

    Если доступа нет: файл выгрузки, загруженный в песочницу — третий законный вход.

Что читаем, что пишем и что нужно от вас

Что подключим

Норма, на которую опирается работа

Краевые случаи

Где решает человек, а не агент

  • Данные испорчены исторически

    Агент показывает объём; решение о миграции и потере — за владельцем.

  • Запрос тяжёлый

    Агент не запускает его на боевой базе в час пик: сначала тестовый контур.

  • Нужны персональные данные

    Агент останавливается: сверка идёт по обезличенным или агрегированным строкам.

  • Правило не задано

    Агент предлагает правило («сумма заказа равна сумме строк») и ждёт подтверждения.

Что обычно возражают

  • «Разработчик сам посмотрит в базе»

    Посмотрит — после дефекта. Запрос с числом экономит этот круг.

  • «Доступ к базе не дадим»

    Тогда работаем по выгрузке в песочнице: результат тот же, риска меньше.

  • «Это же данные, а не код»

    Половина дефектов живёт на стыке: код пишет не то, что ждут, и данные это показывают.

  • «Кто отвечает за исправление данных?»

    Владелец данных; агент даёт объём и список затронутых строк.

  • «Почему 1857 расхождений по строкам?»

    Потому что в кейсе суммы строк не сходятся с заказом — это и есть находка, а не сбой запроса.

Границы

Чего агент не делает

Не пишет в базу: только чтение, без UPDATE и DELETE. Не выгружает персональные данные (152-ФЗ). Не запускает тяжёлые запросы на боевой базе в рабочее время. Не объявляет данные испорченными без правила, с которым их сверяли. Гарантий нет — ст. 5 ФЗ-38.

Вопросы, которые задают первыми

С чего начать?

Пришлите схему базы и один спорный дефект — вернём запросы и число расхождений.

Что нужно от нас?

Роль только на SELECT и адрес тестового контура. Или выгрузку — тогда без доступа.

Это заменит DBA?

Нет: агент находит расхождения и считает объём, исправление — за командой.

Насколько тяжёлые запросы?

JOIN и GROUP BY по таблицам до сотен тысяч строк; на боевой базе не запускаем.

Как проверить, что стало чисто?

Тот же набор запросов после исправления: ноль находок — это доказательство.

Роль целиком

Что ещё берёт на себя агент

Роли

Сверить данные по одному дефекту

Пришлите схему и спорный случай — вернём запросы, число расхождений и вывод, где искать причину.

Telegram
MAX
Открыть чат