Claude Codeи базы данных

База данных — это место, где живут реальные данные проекта: юзеры, заказы, посты. С Claude Code можно перестать вспоминать точный синтаксис SQL и формулировать запросы словами: «посчитай, сколько юзеров пришло за неделю, разбей по дням». Агент составит запрос сам. Но у работы с базой есть жёсткая граница: одна неаккуратная команда — и данные не вернуть. Поэтому весь гайд про две вещи сразу: как делегировать рутину и как не дать агенту что-нибудь снести.

Часть 1 · Контекст

Дай Claude схему базы

Расшифруем термины. Схема (schema) — это описание структуры базы: какие есть таблицы, какие в них колонки, какого типа и как они связаны между собой. DDL (Data Definition Language) — это SQL-команды вроде CREATE TABLE, которые эту структуру задают. Claude пишет хороший SQL только когда видит схему: иначе он придумывает поле user_name, а у тебя в базе оно называется username, и запрос падает.

Самый простой способ дать контекст — показать файл, где схема уже описана. В проекте с Prisma это schema.prisma, с миграциями — папка migrations/, с TypeORM или Drizzle — файлы моделей. Claude прочитает их при старте, особенно если ты упомянешь путь в CLAUDE.md.

# Покажи агенту, где лежит описание структуры базы
Прочитай schema.prisma и migrations/ — это структура нашей базы.
Дальше будешь писать запросы строго под эти таблицы и колонки.

# Claude построит карту таблиц и связей в голове
# и перестанет выдумывать несуществующие поля

Если схемы в коде нет (например, база чужая), выгрузи структуру дампом — командой вроде pg_dump --schema-only для Postgres — и дай файл агенту. Главное правило: сначала контекст, потом запросы.

Часть 2 · Запросы

SQL-запросы словами

Это главный выигрыш. Раньше ты держал в голове, в каком порядке идут SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, и как написать оконную функцию. Теперь формулируешь задачу бизнес-языком, а агент переводит её в корректный SQL под твой диалект (Postgres, MySQL, SQLite — у них есть отличия).

# Ты пишешь словами:
Посчитай выручку по дням за последние 30 дней.
Только оплаченные заказы. Отсортируй от свежих к старым.

# Claude отдаёт готовый SQL под твою схему:
# SELECT date_trunc('day', created_at) AS day,
#        SUM(total) AS revenue
# FROM orders
# WHERE status = 'paid'
#   AND created_at >= now() - interval '30 days'
# GROUP BY day
# ORDER BY day DESC;

Важный приём — просить объяснение. Добавь «и объясни, что делает каждая строка». Так ты не просто получаешь запрос, а учишься читать SQL и ловишь логические ошибки до того, как они доберутся до базы. Если запрос тяжёлый, попроси добавить EXPLAIN и прикинуть, по каким индексам он пойдёт.

Часть 3 · Подключение

Подключить базу по MCP

MCP (Model Context Protocol) — это стандарт, по которому Claude Code подключается к внешним инструментам, в том числе к базам. Без MCP ты копируешь схему и результаты руками. С MCP агент сам смотрит структуру, выполняет SELECT и приносит данные — цикл «вопрос → запрос → ответ» проходит без тебя как посредника. Что такое MCP в деталях — в гайде про MCP-серверы.

# Готовый сервер для Postgres — server-postgres.
# Передаём строку подключения; держим её в переменной окружения,
# а не вписываем в команду открытым текстом.
claude mcp add postgres -- \
  npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL"

# После этого в чате можно просить:
#   "покажи схему таблицы orders"
#   "сколько активных подписок прямо сейчас"
# Claude сходит в базу сам

Ключевой момент безопасности — read-only доступ. Дай MCP-серверу пользователя базы, у которого есть права только на чтение. Тогда даже если агент решит что-то изменить, база ему не позволит: физически невозможно удалить или перезаписать данные через канал, открытый только на SELECT.

Часть 4 · Изменения структуры

Миграции без правки SQL руками

Миграция — это файл, который описывает переход базы из одного состояния в другое: «добавить колонку», «создать таблицу», «навесить индекс». Они нумеруются и применяются по порядку, чтобы у всех разработчиков и на сервере была одинаковая структура. Опасность — когда агент сам сочиняет SQL внутри миграции: легко получить невалидную команду или потерю данных при откате.

Схему меняй декларативно, а миграцию пусть сгенерирует инструмент, не агент вручную.

Правильный воркфлоу: Claude правит описание модели (например, schema.prisma — добавляет поле, индекс, связь), а сам файл миграции создаёт штатная команда генерации. Так SQL пишет проверенный генератор, а не модель «на глаз», и у миграции есть откат.

# 1. Агент меняет ОПИСАНИЕ схемы, а не SQL:
#    в schema.prisma добавляет поле phone в модель User

# 2. Миграцию генерирует штатный инструмент проекта
#    (команда генерации миграций из вашего стека)

# 3. Ты читаешь готовый файл миграции глазами

# 4. Применяешь миграцию сам — отдельным шагом,
#    не доверяя это автономному агенту

Перед изменением структуры включи план-режим (Shift+Tab): агент сначала распишет, что и зачем меняет, ты утверждаешь, и только потом он трогает файлы. Для базы это особенно важно — увидеть план до изменений дешевле, чем откатывать.

Часть 5 · Безопасность

Воркфлоу без потери данных

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

1. Read-only по умолчанию. MCP-подключение и доступ к базе — на чтение. Запись включается осознанно и точечно.
2. Меняющие запросы — через ревью. Любой UPDATE, DELETE, DROP сначала читаешь глазами, потом запускаешь сам.
3. Бэкап перед изменением. Перед миграцией или массовым апдейтом — свежая копия. Это твоя кнопка «отменить».
4. Сначала на копии. Тяжёлые операции прогоняй на тестовой базе или дампе, а не сразу на проде.
5. Права в settings.json. Опасные команды занеси в deny или ask — см. гайд про права.

Вопросы

Частые вопросы

Читать дальше

Соседние гайды