База данных в n8n: как хранить обращения в Data Tables
Сохраняем обращения внутри n8n: поля таблицы, чтение, обновление по ID и проверка повторного запуска без отдельной базы данных.
После ручного разбора обращений хочется сохранить результат так, чтобы следующий запуск workflow мог найти его по ID. Для небольшого прототипа отдельный сервер базы данных может быть лишним шагом. В n8n есть Data Tables — таблицы, доступные из workflow и интерфейса проекта.
1. Определи, что именно хранить
Наш результат — реестр обращений для продуктовой команды: один стабильный ID, короткий текст и состояние разбора. Здесь мы храним рабочие записи, а не историю каждого изменения. Если нужна полноценная история, её следует проектировать отдельно.
Не путай такую таблицу с внутренней базой, где n8n хранит собственные настройки и исполнения. Data Tables — пользовательские данные проекта. Для большой продуктовой базы со сложными связями и требованиями к нагрузке понадобится другой выбор хранилища; это упражнение рассчитано на небольшой реестр.
Подготовь три учебные записи, не содержащие персональных данных:
| request_id | summary | status |
|---|---|---|
| R101 | Не нахожу кнопку приглашения | new |
| R102 | Не приходит письмо с приглашением | new |
| R103 | Нужен выбор цвета карточек | reviewed |
ID нужен для повторного обращения к той же записи. Название проблемы для этого не подходит: его могут отредактировать. Если данные приходят из нескольких систем, используй устойчивый составной ключ, например источник плюс номер обращения, чтобы номера не столкнулись.
2. Создай таблицу в проекте
Открой свой проект n8n → Data tables → Create Data table. Назови таблицу product_requests, выбери создание с нуля и добавь три текстовых столбца из примера. Внеси учебные записи вручную. Другой вариант — импорт CSV; оба способа описаны в официальной инструкции.
Проверь, что R101 хранится целиком, а состояния написаны одинаково: new и reviewed. «New», «новое» и «new » с пробелом усложнят фильтрацию. На первом примере договорись о двух разрешённых значениях и не проси ИИ изобретать новые статусы.
По умолчанию таблицы доступны участникам соответствующего проекта; учитывай это при выборе реальных данных. Для командных ролей есть отдельный разбор проектов n8n. Тестовый реестр лучше отделить от рабочего по названию и назначению.
3. Прочитай запись через workflow
Создай workflow с Manual Trigger и узлом Data Table. Выбери ресурс Row, операцию Get и таблицу product_requests. Задай условие равенства request_id значению R101. Выполни узел и открой Output.
Ожидается одна запись про кнопку приглашения. Если вернулось две, сначала найди дубли в таблице. Если ни одной — сравни ключи, пробелы и выбранный проект. Не заменяй фильтр на возврат всех записей просто ради зелёного индикатора выполнения.
Узел поддерживает чтение и изменения строк, включая Upsert. Операции перечислены в справке Data Table. Перед передачей полей дальше полезно проверить сопоставление данных между узлами.
4. Обнови статус по устойчивому ключу
Для отдельного ручного теста добавь Edit Fields после Manual Trigger: задай request_id = R101, summary = Не нахожу кнопку приглашения, status = reviewed. Соедини его с Data Table, выбери Upsert и условие совпадения по request_id. Передай три поля из входа в соответствующие столбцы.
Upsert обновляет совпавшую запись, а если совпадения нет — создаёт новую. Проверь настройки условия особенно внимательно: без правильного ключа автоматизация может обновить не то обращение или создать повтор.
Выполни тест и открой таблицу. Затем повтори тот же запуск. В последовательном учебном тесте должно остаться три записи, а R101 — получить reviewed. Такой тест не доказывает защиту от гонок при одновременных запусках. Для процесса с параллельной записью отдельно проверь требования к уникальности и поведению при конкурирующих изменениях.
5. Прими результат по контрольным случаям
| Тест | Ожидаемое состояние |
|---|---|
| Get по R101 | Одна нужная запись |
| Повтор того же Upsert | Нет дополнительной строки |
| Новый ключ R104 | Появилась одна новая запись |
| Ключ не передан | Запись остановлена до узла сохранения |
Проверку непустого ключа добавь перед записью через Filter или If. Сообщение без ID отправляй на разбор, а не подставляй случайный номер. ИИ можно поручить сформулировать описание, но ключ и допустимые статусы должны задаваться процессом.
Моя рекомендация: начни с трёх записей и второго одинакового запуска. Это быстрее выявляет ошибку хранения, чем красивый workflow с моделью, уведомлениями и сотней строк.
Когда реестр проверен, подключай источник обращений, например GitHub Issues. Добавляй автоматические действия по одному и сохраняй возможность открыть исходное обращение.
Проверка материала: официальные источники сверены 13 октября 2026 года. Пример учебный; реальный запуск в аккаунте пользователя не выполнялся.
Последовательно освоить такие рабочие сценарии можно на курсе AI Product Club.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗