База данных хранит связи и правила учёта: агенты меняют структуру вместе с функцией продукта

Владелец покупает возможность ответить на вопрос «что мы должны покупателю?». Для этого нужны сам заказ, его состав и состояние исполнения.

Возьмём учебный интернет-магазин. Покупатель оформил заказ, затем менеджер изменил цену товара в каталоге. Сумма прежней покупки должна остаться прежней.

У каждой записи есть свой номер, а у заказа есть связи с покупателем и товарами. В заказанной CRM эти отношения тоже важнее цвета таблицы.

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

Наличие базы само по себе не запрещает ошибку. Разработчик должен описать, какие записи допустимы и что система делает при конфликте.

В PostgreSQL связь можно закрепить ограничением, которое не даст сослаться на отсутствующий товар. Отдельные проверки запрещают пустые обязательные поля и повтор номера.

Создание заказа и резерв товара можно объединить в операцию внутри базы. Все её действия сохранятся вместе либо не сохранятся вовсе. Так работает транзакция.

Транзакция базы не отменяет внешний платёж или уже отправленное письмо. Для таких действий серверной программе нужны свои правила повторов и проверки результата.

Кнопка «Отгрузить частично» меняет смысл заказа. Одного общего состояния уже недостаточно: нужно хранить состав каждой отправки.

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

Stripe описала такой поворот в феврале 2017 года. Несколько подписок сначала хранили списком в карточке покупателя. Когда новые функции усложнили работу с этим списком, подписки вынесли в отдельную таблицу.

Пустая тестовая база не покажет, что будет с прежними заказами. Проверка должна включать записи старого формата, а не только покупку после обновления.

Миграцией называют подготовленное изменение структуры или перенос сохранённых данных. Это задача вместе с новой функцией, даже если пользователь не видит переноса.

Документация Prisma предлагает сначала расширить структуру и перенести данные, затем убрать старое. Stripe во время перехода сравнивала результаты чтения.

Нельзя восстановить даты отгрузок, которые система никогда не сохраняла. Такие пробелы согласуют с владельцем учёта; агент не заполняет их догадками.

Инженер ведёт машину агентов на vibecoding.ru, включая бэкенд и базу. Это видно на публичной карте машины; сама карта не оценивает качество конкретной СУБД.

В курсе агентной разработки база входит в устройство рабочего продукта. Собственный кабинет курса показывает другую сторону задачи: ответы анкеты сохраняются в карточке ученика.

Ответ привязан к версии вопросов. Когда вопрос меняют для следующих учеников, прежний ответ сохраняет прежний смысл. Это наш продукт, клиентского сравнения «до и после» здесь нет.

Изменение поля должно пройти через все места, которые его сохраняют и читают. Наши ошибки были именно на этих связях между частями программы.

В разборе технического долга речь о накопленных проблемах кода. Здесь причина уже в новой функции: её данные должны дойти до каждого нужного экрана.

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

В задаче сначала фиксируют, что должно остаться верным. Для нашего заказа это прежняя цена, состав покупки и предел отправленного количества.

Эти условия входят в постановку задачи агенту. Исполнитель сдаёт изменение таблиц, серверные правила и проверку рабочего сценария одним результатом.

До выпуска согласуют способ возврата при сбое. Возврат к старому коду должен учитывать уже записанные новые данные; ответственность за ошибки разобрана отдельно.

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

В разработке по подписке тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Это один продукт и один поток работы.

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

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

1. База хранит записи и связи. Назовите, какие отношения система должна сохранять после изменения.
2. Новая функция меняет учёт. Принимайте её вместе со структурой данных и серверными правилами.
3. Прежние записи проверяют отдельно. Попросите показать старый заказ в новом сценарии.
4. Историю нельзя додумать. Согласуйте перенос пробелов и сохранение первоначальных фактов до выпуска.
5. Работу подтверждает сценарий. Проверьте повтор запроса, отказ операции и продолжение переноса.