Claude Код 👁 3

Запись из n8n в базу: транзакции и повторы

Промпт для Claude: настроить запись из n8n в PostgreSQL — вставка с обновлением при конфликте, пачки и поведение при обрыве.

Промпт Запустить →
Помоги настроить запись данных из n8n в PostgreSQL.

Что пишу: [ДАННЫЕ: события из внешнего сервиса — event_id, тип, полезная нагрузка в JSON, время]
Таблица: [ТАБЛИЦА: events, есть уникальный индекс по event_id]
Объём: [ОБЪЁМ: 500-2000 событий в сутки, приходят пачками до 50]
Что беспокоит: [СТРАХ: сервис присылает одно событие несколько раз, и при обрыве связи мы не знаем, что записалось]

Что нужно:

1. Какую операцию ноды взять под мой случай и чем вставка отличается от вставки с обновлением при конфликте. У меня есть уникальный индекс — покажи, как использовать его, чтобы повтор не ломал запись и не плодил строки.
2. Полезная нагрузка приходит структурой. Скажи, в каком виде её класть в базу и что выбрать: отдельные колонки или одно поле. Дай критерий выбора, а не оба варианта.
3. Пачка из пятидесяти: запишется ли она одной операцией или пятьюдесятью, и что произойдёт при ошибке на тридцатой. Мне нужно понимать, окажется ли база в состоянии «половина записана».
4. Как узнать постфактум, какие события дошли. Назови проверочный запрос, который покажет разрыв в последовательности за сутки.
5. Учётные данные и доступ: где они задаются, почему не в самой ноде, и какой минимум прав нужен пользователю базы для этой задачи.

Отсечка. Не предлагай отключать уникальный индекс, чтобы «не мешал». Не советуй писать через ноду Code и собственное подключение: у ноды базы есть всё нужное. Не предлагай хранить всё одной строкой текста ради простоты — по этому полю потом придётся искать.

Проверка перед выдачей: опиши поведение схемы при трёх ситуациях — одно и то же событие пришло дважды, пачка оборвалась на середине, сервис прислал событие с пустой нагрузкой. Если хотя бы в одной база остаётся в непонятном состоянии, скажи об этом прямо и предложи, чем это закрыть.
Запустить промпт →

Пример результата

Пробовал на приёме событий внешнего сервиса, около тысячи в сутки, PostgreSQL рядом с n8n. Что вышло: операция со вставкой и обновлением при конфликте по уникальному индексу решила главную проблему — повторные события перестали ронять запись. До этого воркфлоу падал на каждом дубле. Второй пункт дал внятный критерий: нагрузку кладём одним полем, потому что структура у разных типов событий разная, а поиск идёт по типу и времени, которые вынесены в отдельные колонки. Третий пункт неприятно удивил: пачка пишется по элементам, и при ошибке на тридцатой первые двадцать девять остаются. Добавил проверку из четвёртого пункта — запрос на разрывы в последовательности, гоняю раз в сутки. Совет: пятый пункт про права не пропускайте. У меня пользователь базы имел права на удаление, которые для этой задачи не нужны вовсе.

Похожие промпты

Рефакторинг легаси-модуля в Kimi: карта, план, код по шагам
Kimi
Рефакторинг легаси-модуля в Kimi: карта, план, код по шагам
Kimi
Сайт-визитка с 3D одним промптом — Kimi K3
DeepSeek
Телеграм-бот на n8n в DeepSeek: схема нод, которую можно собрать за вечер
Claude
Системный промпт для AI Agent ноды n8n — Claude

Полезные статьи

ИИ-агенты в n8n: промт, сборка агента и грабли запуска
Промты для Kling: видео из фото и 14 готовых промптов
Промт с котом: 4 провала нейросети и 14 промптов

Все гайды →