Промпты для разработчика баз данных. 27 готовых примеров для генерации

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

Здесь собраны 27 конкретных примеров: от проектирования схем и написания сложных запросов до оптимизации производительности и документирования структур. Каждый промпт можно скопировать, заполнить под свою задачу и получить результат.

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

Что найдете внутри:

• 27 готовых промптов по ключевым задачам разработки баз данных
• Типичные ошибки при составлении запросов к нейросети – чтобы не наступать на чужие грабли
• Сравнительная таблица слабых и сильных формулировок для задач ниши
• Неочевидные советы по работе с нейросетью в контексте баз данных

27 промптов для разработчика баз данных: готовые примеры

1. Проектирование схемы реляционной базы данных

Проблема: Когда нужно спроектировать схему с нуля, легко упустить связи между сущностями или выбрать неподходящие типы данных – и переделывать потом все.

Решение: Промпт заставляет нейросеть выступить в роли опытного архитектора и выдать полноценную схему с обоснованием каждого решения.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный архитектор баз данных с опытом проектирования систем для электронной коммерции”].

Спроектируй реляционную схему базы данных для следующей предметной области: [опишите область, например, “система управления заказами интернет-магазина: клиенты, товары, категории, заказы, позиции заказов, доставка”].

Контекст: [укажите контекст, например, “система должна поддерживать до 500 000 активных клиентов, хранить историю заказов за 5 лет, работать с PostgreSQL 15”].

Выполни следующее:

1. Перечисли все сущности (таблицы) с их атрибутами и типами данных.
2. Укажи первичные и внешние ключи для каждой таблицы.
3. Опиши связи между таблицами (один-к-одному, один-ко-многим, многие-ко-многим).
4. Для таблиц связи “многие-ко-многим” создай промежуточные таблицы.
5. Укажи, какие поля стоит проиндексировать и почему.
6. Отметь, если где-то есть риск избыточности данных или нарушения нормальной формы.

Формат ответа: сначала текстовое описание каждой таблицы, затем SQL-код CREATE TABLE для всех таблиц в правильном порядке (с учетом зависимостей внешних ключей).

Ограничения: не используй устаревшие типы данных, избегай хранения вычисляемых значений в таблицах, не создавай избыточных связей.

*****

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

2. Написание сложного SQL-запроса с несколькими условиями

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

Решение: Промпт дает нейросети всю необходимую структуру таблиц и логику задачи, чтобы получить рабочий запрос с объяснением.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный разработчик SQL с глубоким знанием PostgreSQL и аналитических функций”].

Напиши SQL-запрос для следующей задачи: [опишите задачу, например, “найти топ-10 клиентов по сумме заказов за последние 90 дней, у которых было не менее 3 заказов, и показать их имя, общую сумму, количество заказов и средний чек”].

Структура таблиц:
[вставьте описание таблиц, например:
“clients (id, name, email, created_at)
orders (id, client_id, total_amount, status, created_at)
– статус может быть: ‘completed’, ‘cancelled’, ‘pending'”]

СУБД: [укажите, например, “PostgreSQL 15”].

Требования к запросу:

1. Учитывать только заказы со статусом ‘completed’.
2. Использовать оконные функции там, где это уместно.
3. Добавить комментарии к каждому смысловому блоку запроса.
4. После запроса объясни логику каждого шага.

Ограничения: не используй подзапросы там, где можно обойтись соединениями; избегай конструкций, которые плохо масштабируются на больших таблицах.

*****

Почему это работает: Передача структуры таблиц устраняет главную причину нерабочих запросов от нейросети – она перестает догадываться о названиях полей и начинает работать с реальными данными.

3. Оптимизация медленного SQL-запроса

Проблема: Запрос работает, но выполняется 30 секунд вместо 0,3 – и непонятно, где именно узкое место.

Решение: Промпт направляет нейросеть на системный разбор запроса с анализом плана выполнения и конкретными рекомендациями по ускорению.

Текст промпта:

*****

Ты – [укажите роль, например, “эксперт по оптимизации баз данных PostgreSQL с опытом работы с таблицами от 10 миллионов записей”].

Проанализируй и оптимизируй следующий SQL-запрос: [вставьте текст запроса].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 14”] – Примерный объем таблиц: [укажите, например, “таблица orders – 8 млн строк, таблица clients – 500 тысяч строк”] – Текущее время выполнения: [укажите, например, “28 секунд на продакшн-сервере”] – Вывод EXPLAIN ANALYZE (если есть): [вставьте или напишите “недоступен”] – Существующие индексы: [перечислите или напишите “неизвестны”]

Выполни следующее:

1. Найди все проблемные места в запросе (полный перебор таблиц, отсутствие индексов, неэффективные соединения, лишние подзапросы).
2. Объясни причину медленной работы каждого блока.
3. Предложи оптимизированную версию запроса.
4. Укажи, какие индексы нужно создать и почему.
5. Оцени ожидаемый прирост производительности.

Формат: сначала диагностика, затем исправленный запрос, затем SQL для создания индексов.
Ограничения: не меняй логику запроса, только его производительность.

*****

Почему это работает: Контекст об объеме таблиц критически важен – без него нейросеть предложит решения, которые работают на тысячах строк, но бесполезны на миллионах.

4. Создание стратегии индексирования для таблицы

Проблема: Индексы создаются интуитивно – “вот это поле часто используется в WHERE, добавим индекс”. В итоге индексов много, запись замедляется, а нужные запросы все равно тормозят.

Решение: Промпт дает системный подход к выбору индексов с учетом реальных паттернов использования таблицы.

Текст промпта:

*****

Ты – [укажите роль, например, “специалист по настройке производительности баз данных с опытом работы с высоконагруженными системами”].

Разработай стратегию индексирования для следующей таблицы: [вставьте DDL таблицы или ее описание, например, “таблица transactions (id, user_id, merchant_id, amount, currency, status, created_at, updated_at) – 50 млн записей, прирост 200 тысяч в сутки”].

Паттерны использования таблицы:
[опишите типичные запросы, например:
“1. Выборка транзакций по user_id за период (90% операций чтения)
2. Агрегация по merchant_id и статусу за месяц (аналитика)
3. Поиск транзакций по статусу ‘pending’ (фоновый процесс)
4. Обновление статуса по id (высокая частота)”]

СУБД: [укажите, например, “PostgreSQL 15”].

Ответь на следующие вопросы:

1. Какие индексы создать и какого типа (B-tree, Hash, GIN, частичный)?
2. Какой порядок полей в составных индексах и почему?
3. Какие индексы могут навредить и от чего отказаться?
4. Как проверить, что индексы используются (конкретные команды)?
5. Приведи SQL для создания каждого индекса.

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

*****

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

5. Написание хранимой процедуры

Проблема: Хранимые процедуры с обработкой ошибок, транзакциями и логированием – это объем кода, который легко написать с багами, если делать вручную.

Решение: Промпт задает все требования к процедуре и получает готовый, рабочий код с обработкой исключений.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных PostgreSQL с опытом написания хранимых процедур для финансовых систем”].

Напиши хранимую процедуру для следующей задачи: [опишите задачу, например, “перевод средств между счетами пользователей: списать сумму со счета отправителя, зачислить на счет получателя, записать транзакцию в журнал”].

Структура связанных таблиц:
[вставьте описание, например:
“accounts (id, user_id, balance, currency, status)
transactions_log (id, from_account_id, to_account_id, amount, status, created_at, error_message)”]

СУБД: [укажите, например, “PostgreSQL 15”].

Требования к процедуре:

1. Использовать транзакцию с откатом при любой ошибке.
2. Проверять: достаточность баланса, статус счетов (‘active’), совпадение валют.
3. Записывать в журнал как успешные операции, так и ошибки с кодом и описанием.
4. Возвращать статус выполнения и сообщение об ошибке.
5. Использовать блок EXCEPTION для обработки исключений.

Формат: полный код процедуры с комментариями, затем пример вызова процедуры.
Ограничения: не использовать динамический SQL без крайней необходимости; процедура должна быть идемпотентной при повторном вызове с теми же параметрами.

*****

Почему это работает: Требование идемпотентности и явное описание сценариев ошибок заставляют нейросеть написать процедуру, которая не сломает данные при сбое или повторном вызове – это именно то, что обычно упускают при быстром написании.

6. Разработка стратегии резервного копирования

Проблема: Стратегия резервного копирования часто сводится к “делаем дамп раз в сутки” – пока не случится инцидент и не выяснится, что последний рабочий бэкап был три дня назад.

Решение: Промпт помогает выстроить полноценную стратегию с учетом требований к восстановлению и доступным ресурсам.

Текст промпта:

*****

Ты – [укажите роль, например, “администратор баз данных с опытом построения систем резервного копирования для критичных бизнес-приложений”].

Разработай стратегию резервного копирования для базы данных со следующими параметрами:
– СУБД: [укажите, например, “PostgreSQL 15”] – Объем базы данных: [укажите, например, “800 ГБ, прирост 5 ГБ в сутки”] – Допустимая потеря данных: [укажите, например, “не более 1 часа”] – Допустимое время восстановления: [укажите, например, “не более 4 часов”] – Доступное хранилище: [укажите, например, “локальный сервер 2 ТБ + объектное хранилище Яндекс.Облако 10 ТБ”] – Критичность: [укажите, например, “финансовые данные, требования регулятора – хранить 5 лет”]

Ответь на следующие вопросы:

1. Какую комбинацию типов резервных копий использовать (полная, инкрементальная, непрерывное архивирование журналов)?
2. Расписание создания копий с обоснованием.
3. Схема хранения и ротации копий.
4. Как проверять целостность резервных копий (конкретные команды).
5. Процедура восстановления – пошагово.
6. Какие инструменты использовать (pgBackRest, pg_dump, WAL-G) и почему.

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

*****

Почему это работает: Параметры “допустимая потеря данных” и “допустимое время восстановления” – это конкретные бизнес-требования, которые определяют всю архитектуру резервного копирования. Без них нейросеть выдает универсальные советы, которые не подходят ни для одной конкретной ситуации.

7. Проектирование схемы для временных рядов данных

Проблема: Временные ряды – метрики, события, показания датчиков – при хранении в обычных реляционных таблицах быстро превращаются в миллиарды строк, которые тормозят любой запрос.

Решение: Промпт помогает выбрать правильный подход к хранению и секционированию данных временных рядов.

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор данных с опытом проектирования систем хранения временных рядов для промышленных приложений”].

Спроектируй схему хранения для следующих данных: [опишите данные, например, “показания датчиков температуры, давления и вибрации с 500 промышленных устройств, частота записи – каждые 10 секунд с каждого устройства”].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 15 с расширением TimescaleDB” или “только стандартный PostgreSQL”] – Горизонт хранения: [укажите, например, “горячие данные – 30 дней, архив – 2 года”] – Типичные запросы: [опишите, например, “агрегация по устройству за период, поиск аномалий, построение трендов”] – Объем: [укажите, например, “около 4 млн записей в сутки”]

Ответь на следующие вопросы:

1. Какую структуру таблиц использовать?
2. Как организовать секционирование (partitioning) и по какому ключу?
3. Как хранить данные разной детализации (сырые данные vs. агрегаты)?
4. Как реализовать автоматическое удаление или перемещение устаревших данных?
5. Какие индексы создать с учетом специфики временных рядов?
6. Приведи DDL для всех таблиц.

Ограничения: решение должно масштабироваться без смены СУБД; избегай схем, требующих ручного обслуживания.

*****

Почему это работает: Разделение на “горячие” и архивные данные с конкретными сроками – это именно тот контекст, который позволяет нейросети предложить секционирование с правильным ключом, а не просто создать одну таблицу с индексом по дате.

8. Написание триггера для аудита изменений

Проблема: Отслеживать, кто и когда изменил запись – стандартная задача, которая при ручной реализации обрастает ошибками: забытые поля, неправильный захват старых значений, отсутствие логирования удалений.

Решение: Промпт создает полноценный аудиторский триггер, который фиксирует все изменения с сохранением старых и новых значений.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных PostgreSQL с опытом реализации систем аудита для приложений с требованиями соответствия регуляторным нормам”].

Напиши триггер аудита для следующей таблицы: [вставьте DDL таблицы или ее описание, например, “таблица employees (id, full_name, position, salary, department_id, status, updated_at, updated_by)”].

Требования к аудиту:
– Отслеживать операции: [укажите, например, “INSERT, UPDATE, DELETE”] – Фиксировать: старые значения, новые значения, тип операции, время, пользователя БД
– Хранить: [укажите, например, “в отдельной таблице employees_audit”] – Особые условия: [укажите, например, “не логировать изменения поля updated_at; логировать только изменения salary отдельным флагом”]

СУБД: [укажите, например, “PostgreSQL 15”].

Выполни следующее:

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

Ограничения: не используй динамический SQL в триггере; таблица аудита не должна влиять на производительность основной таблицы.

*****

Почему это работает: Указание особых условий – например, не логировать технические поля – критично. Без этого нейросеть создает триггер, который пишет тысячи бесполезных записей при каждом автоматическом обновлении временных меток.

9. Миграция данных между схемами

Проблема: Миграция данных из старой схемы в новую – это всегда риск потери данных, нарушения целостности или простоя системы. Особенно когда схемы принципиально разные.

Решение: Промпт создает пошаговый план миграции с проверками целостности и возможностью отката.

Текст промпта:

*****

Ты – [укажите роль, например, “инженер по работе с данными с опытом проведения крупных миграций без простоя продакшн-систем”].

Разработай план миграции данных для следующей ситуации:

Исходная схема (старая): [опишите или вставьте DDL, например, “таблица users с полями: id, name (ФИО одной строкой), address (адрес одной строкой), phone, email, created_date (тип VARCHAR)”].

Целевая схема (новая): [опишите или вставьте DDL, например, “таблица clients: id, first_name, last_name, middle_name, city, street, phone_mobile, phone_home, email, created_at (тип TIMESTAMP)”].

Контекст:
– Объем данных: [укажите, например, “2,3 млн строк”] – Допустимый простой: [укажите, например, “не более 30 минут в ночное окно”] – СУБД: [укажите, например, “PostgreSQL 14”] – Особые сложности: [опишите, например, “поле name нужно разбить на части, address – парсить, created_date содержит даты в разных форматах”]

Выполни следующее:

1. Пошаговый план миграции с оценкой времени каждого шага.
2. SQL-скрипт преобразования данных с обработкой нестандартных случаев.
3. Проверочные запросы для валидации результата миграции.
4. Скрипт отката на случай критической ошибки.
5. Как минимизировать простой системы.

Ограничения: скрипт миграции должен быть идемпотентным; не удалять исходные данные до подтверждения успешной миграции.

*****

Почему это работает: Описание “особых сложностей” – разные форматы дат, составные поля – это именно те детали, которые превращают простую миграцию в проблему. Нейросеть, получив их заранее, закладывает обработку нестандартных случаев в скрипт, а не оставляет их на потом.

10. Проектирование структуры для многоарендной системы

Проблема: Многоарендные системы (когда одна база обслуживает множество клиентов-организаций) требуют четкого решения по изоляции данных – и каждый подход имеет свои подводные камни, которые проявляются не сразу.

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

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор SaaS-платформ с опытом проектирования многоарендных систем на PostgreSQL”].

Спроектируй архитектуру базы данных для многоарендной системы со следующими параметрами:
– Описание системы: [опишите, например, “платформа для управления проектами, которой пользуются разные компании-клиенты”] – Ожидаемое количество арендаторов: [укажите, например, “от 100 до 5000 компаний”] – Объем данных на арендатора: [укажите, например, “в среднем 50 тысяч записей, максимум – 5 млн”] – Требования к изоляции: [укажите, например, “строгая: утечка данных между арендаторами недопустима”] – Требования к настройке: [укажите, например, “каждый арендатор может иметь кастомные поля в сущностях”] – СУБД: [укажите, например, “PostgreSQL 15”]

Сравни три подхода применительно к моим параметрам:

1. Общая схема с полем tenant_id в каждой таблице.
2. Отдельная схема (schema) PostgreSQL на каждого арендатора.
3. Отдельная база данных на каждого арендатора.

Для каждого подхода укажи: плюсы, минусы, риски, подходящий масштаб.
Затем выбери оптимальный подход для моих параметров и предоставь DDL для ключевых таблиц.

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

*****

Почему это работает: Запрос сравнения трех подходов с привязкой к конкретным параметрам системы заставляет нейросеть не просто описать теорию, а применить ее к реальной ситуации и обосновать выбор – что и нужно при проектировании.

11. Анализ и устранение взаимоблокировок

Проблема: Взаимоблокировки (дедлоки) в базе данных – это те самые ошибки, которые воспроизводятся только под нагрузкой и исчезают при попытке отладить их вручную.

Решение: Промпт помогает систематически диагностировать причины взаимоблокировок и устранить их на уровне запросов и транзакций.

Текст промпта:

*****

Ты – [укажите роль, например, “специалист по диагностике проблем производительности PostgreSQL с опытом работы с высоконагруженными системами”].

Помоги диагностировать и устранить взаимоблокировки в следующей ситуации:

Описание проблемы: [опишите, например, “в часы пик (с 10 до 12 дня) в логах PostgreSQL появляются ошибки deadlock detected, приложение падает с ошибкой примерно раз в 15 минут”].

Фрагменты из логов PostgreSQL (если есть): [вставьте или напишите “недоступны”].

Транзакции, которые предположительно конфликтуют:
[опишите или вставьте код, например:
“Транзакция 1: обновляет баланс пользователя, затем создает запись в журнале транзакций
Транзакция 2: создает запись в журнале транзакций, затем обновляет баланс пользователя”]

СУБД: [укажите, например, “PostgreSQL 14”].

Выполни следующее:

1. Объясни механизм возникновения взаимоблокировки в данной ситуации.
2. Покажи SQL-запросы для диагностики текущих блокировок в реальном времени.
3. Предложи 3–5 способов устранения проблемы (порядок блокировок, уровни изоляции, оптимистичная блокировка).
4. Для каждого способа укажи: как реализовать, риски, подходящие сценарии.
5. Рекомендуй оптимальное решение для описанного случая.

Ограничения: решение не должно требовать изменения бизнес-логики приложения; предпочтительны изменения на уровне базы данных.

*****

Почему это работает: Описание порядка операций в конфликтующих транзакциях – это ключевой контекст. Именно порядок захвата блокировок определяет, возникнет ли дедлок, и нейросеть не сможет предложить правильное решение без этой информации.

12. Написание документации для схемы базы данных

Проблема: Документация базы данных либо отсутствует, либо устарела на три версии – новые разработчики тратят дни на понимание схемы, которую можно было объяснить за час.

Решение: Промпт создает структурированную документацию схемы, понятную как разработчикам, так и аналитикам.

Текст промпта:

*****

Ты – [укажите роль, например, “технический писатель с опытом документирования сложных систем баз данных”].

Создай документацию для следующей схемы базы данных: [вставьте DDL всех таблиц или их описание].

Аудитория документации: [укажите, например, “разработчики бэкенда и аналитики данных, не знакомые с текущей схемой”].

Документация должна включать:

1. Общее описание назначения базы данных и ее основных сущностей (2–3 абзаца).
2. Для каждой таблицы:
   – Назначение таблицы (1–2 предложения)
   – Описание каждого поля: тип, обязательность, смысл, допустимые значения
   – Связи с другими таблицами
   – Важные бизнес-правила и ограничения
3. Глоссарий ключевых терминов предметной области.
4. Типичные запросы для частых задач (5–7 примеров с комментариями).
5. Известные особенности и подводные камни схемы.

Формат: структурированный текст, пригодный для размещения в корпоративной вики (например, Confluence).
Стиль: технический, точный, без лишних слов.
Ограничения: не переписывай DDL, описывай смысл; избегай фраз типа “данная таблица предназначена для хранения данных о…”

*****

Почему это работает: Явное указание аудитории и запрет на тавтологичные формулировки (“таблица для хранения данных”) заставляют нейросеть писать документацию, которую действительно читают, а не ту, которую создают для галочки.

13. Проектирование системы полнотекстового поиска

Проблема: Поиск через LIKE ‘%слово%’ работает на маленьких таблицах и умирает на больших – но настройка нормального полнотекстового поиска кажется сложной задачей.

Решение: Промпт создает полноценную реализацию полнотекстового поиска средствами PostgreSQL без внешних систем.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных PostgreSQL с опытом реализации систем поиска для русскоязычного контента”].

Реализуй полнотекстовый поиск для следующей задачи: [опишите задачу, например, “поиск по каталогу товаров: поля name, description, tags; нужна поддержка русского языка, морфологии, поиска по части слова, ранжирование результатов по релевантности”].

Структура таблицы: [вставьте DDL или описание, например, “products (id, name, description, tags, category_id, price, created_at) – 500 тысяч записей”].

Требования:
– Язык контента: [укажите, например, “русский, иногда встречается английский”] – Поля для поиска: [укажите, например, “name (высокий приоритет), description (средний), tags (низкий)”] – Ожидаемая нагрузка: [укажите, например, “до 100 поисковых запросов в секунду”] – Допустимая задержка: [укажите, например, “не более 200 мс”]

Выполни следующее:

1. Объясни выбор словаря (russian, simple или кастомный).
2. Создай вектор поиска: отдельное поле или вычисляемое?
3. Напиши SQL для создания индекса GIN.
4. Покажи SQL для поискового запроса с ранжированием.
5. Как обновлять поисковый вектор при изменении данных (триггер или функция).
6. Как реализовать поиск по части слова (pg_trgm).

Ограничения: не использовать внешние поисковые системы; решение должно работать на стандартном PostgreSQL с расширениями.

*****

Почему это работает: Указание весов полей (высокий / средний / низкий приоритет) – это то, что определяет качество ранжирования результатов. Без этого нейросеть создает поиск, который одинаково ранжирует совпадение в названии и в описании, что дает нерелевантные результаты.

14. Создание системы партиционирования таблицы

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

Решение: Промпт создает полный план внедрения партиционирования для существующей таблицы без потери данных.

Текст промпта:

*****

Ты – [укажите роль, например, “администратор баз данных PostgreSQL с опытом партиционирования таблиц в продакшн-окружении без простоя”].

Разработай план внедрения партиционирования для следующей таблицы: [вставьте DDL или описание, например, “таблица events (id BIGSERIAL PRIMARY KEY, user_id BIGINT, event_type VARCHAR(50), payload JSONB, created_at TIMESTAMP) – 300 млн записей, прирост 2 млн в сутки”].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 14”] – Типичные запросы: [опишите, например, “выборка событий за период, поиск по user_id за период, удаление событий старше 1 года”] – Допустимый простой: [укажите, например, “не более 10 минут”] – Текущие индексы: [перечислите, например, “idx_events_user_id, idx_events_created_at”]

Выполни следующее:

1. Выбери тип партиционирования (по диапазону, по списку, по хешу) с обоснованием.
2. Определи ключ партиционирования и размер партиций.
3. Пошаговый план миграции существующей таблицы на партиционированную.
4. SQL для создания новой партиционированной таблицы и партиций.
5. Как автоматически создавать новые партиции (pg_partman или ручной скрипт).
6. Как настроить автоматическое удаление старых партиций.
7. Проверочные запросы для контроля корректности миграции.

Ограничения: план должен позволять откат на исходную схему; минимизировать время блокировки таблицы.

*****

Почему это работает: Описание типичных запросов определяет выбор ключа партиционирования – это не просто технический выбор, а решение, которое напрямую влияет на то, будет ли партиционирование вообще полезным или только усложнит схему.

15. Написание скрипта для генерации тестовых данных

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

Решение: Промпт создает скрипт генерации реалистичных тестовых данных нужного объема с соблюдением всех ограничений схемы.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных с опытом создания реалистичных наборов тестовых данных для нагрузочного тестирования”].

Напиши скрипт генерации тестовых данных для следующей схемы: [вставьте DDL всех таблиц или их описание].

Требования к данным:
– Объем: [укажите, например, “100 тысяч пользователей, 2 млн заказов, 8 млн позиций заказов”] – Реалистичность: [опишите, например, “распределение заказов по пользователям должно быть неравномерным (80% заказов – у 20% пользователей), даты заказов – за последние 2 года с пиками в декабре и марте”] – Граничные случаи: [укажите, например, “5% пользователей без заказов, 1% заказов с нулевой суммой, 0,1% отмененных заказов с уже созданными позициями”] – СУБД: [укажите, например, “PostgreSQL 15”]

Выполни следующее:

1. Скрипт на SQL с использованием generate_series и случайных значений.
2. Соблюдение всех ограничений целостности (внешние ключи, уникальность).
3. Реалистичные значения: имена, email, суммы в разумных диапазонах.
4. Параметры для управления объемом данных (переменные в начале скрипта).
5. Оценка времени выполнения скрипта.

Ограничения: скрипт должен выполняться за разумное время (не более 30 минут для указанного объема); данные не должны нарушать ограничения схемы.

*****

Почему это работает: Требование неравномерного распределения данных – это принципиальный момент. Равномерные тестовые данные не выявляют реальные проблемы производительности, которые возникают именно при скошенном распределении, характерном для реальных систем.

16. Проектирование схемы для хранения иерархических данных

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

Решение: Промпт помогает выбрать оптимальный метод хранения иерархии с учетом реальных операций над данными.

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор баз данных с опытом проектирования иерархических структур данных в PostgreSQL”].

Спроектируй структуру для хранения следующих иерархических данных: [опишите, например, “каталог товаров с неограниченной вложенностью категорий (до 7 уровней на практике), каждая категория может иметь несколько дочерних, нужно быстро получать все товары из категории и всех ее подкатегорий”].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 15”] – Объем: [укажите, например, “до 10 тысяч категорий, до 500 тысяч товаров”] – Частота изменений иерархии: [укажите, например, “редко – 1–2 раза в месяц”] – Основные операции: [перечислите, например, “получить все дерево, получить путь от корня до узла, получить всех потомков узла, переместить поддерево”]

Сравни следующие подходы применительно к моим параметрам:

1. Список смежности (Adjacency List) с рекурсивными запросами (WITH RECURSIVE).
2. Материализованный путь (Materialized Path).
3. Вложенные множества (Nested Sets).
4. Таблица замыкания (Closure Table).

Для каждого подхода: плюсы, минусы, сложность операций чтения и записи.
Затем: рекомендация с DDL и примерами запросов для основных операций.

Ограничения: приоритет – скорость чтения; изменения иерархии могут быть медленнее.

*****

Почему это работает: Указание частоты изменений и приоритета операций – это ключевые параметры выбора. Nested Sets идеальны для чтения, но обновление дерева в них – это пересчет всей таблицы. Нейросеть выберет правильный подход только с этим контекстом.

17. Настройка репликации базы данных

Проблема: Репликация кажется сложной темой с кучей параметров, а ошибка в настройке может привести к потере данных или рассинхронизации реплик.

Решение: Промпт создает пошаговую инструкцию настройки репликации под конкретную задачу с проверками на каждом этапе.

Текст промпта:

*****

Ты – [укажите роль, например, “администратор баз данных PostgreSQL с опытом настройки репликации для продакшн-систем”].

Создай инструкцию по настройке репликации для следующей ситуации:
– Цель репликации: [укажите, например, “высокая доступность + снятие нагрузки чтения на реплику”] – Топология: [укажите, например, “1 первичный сервер + 1 синхронная реплика + 1 асинхронная реплика для аналитики”] – СУБД: [укажите, например, “PostgreSQL 15”] – Версия на всех серверах: [укажите, например, “одинаковая – 15.3”] – Объем базы данных: [укажите, например, “600 ГБ”] – Сеть: [укажите, например, “серверы в одном дата-центре, задержка 1 мс”]

Предоставь:

1. Выбор типа репликации (потоковая, логическая) с обоснованием.
2. Пошаговая настройка первичного сервера: конфигурационные параметры postgresql.conf и pg_hba.conf.
3. Пошаговая настройка каждой реплики.
4. Как создать базовую резервную копию для инициализации реплик.
5. Команды для проверки статуса репликации и отставания реплик.
6. Что делать при отставании реплики более чем на 1 ГБ.
7. Процедура переключения на реплику при сбое первичного сервера.

Ограничения: использовать только встроенные средства PostgreSQL; не использовать сторонние инструменты типа Patroni (если только не потребуется для автоматического переключения).

*****

Почему это работает: Разграничение синхронной и асинхронной реплик с разными целями – это реальная архитектурная задача. Без этого контекста нейросеть опишет только один тип репликации, что не даст нужного результата.

18. Анализ плана выполнения запроса

Проблема: Вывод EXPLAIN ANALYZE выглядит как зашифрованное сообщение для тех, кто не занимается оптимизацией ежедневно – а именно там скрыты все причины медленной работы запроса.

Решение: Промпт помогает расшифровать план выполнения и найти конкретные узкие места с рекомендациями по исправлению.

Текст промпта:

*****

Ты – [укажите роль, например, “эксперт по оптимизации запросов PostgreSQL, умеющий читать планы выполнения и находить узкие места”].

Проанализируй следующий план выполнения запроса:

Запрос: [вставьте SQL-запрос]

Вывод EXPLAIN ANALYZE: [вставьте полный вывод]

Контекст:
– СУБД: [укажите, например, “PostgreSQL 14”] – Объем таблиц: [укажите если известно, например, “orders – 12 млн строк, clients – 800 тысяч строк”] – Текущее время выполнения: [укажите, например, “14 секунд”] – Целевое время: [укажите, например, “менее 500 мс”]

Выполни следующее:

1. Объясни план выполнения простым языком: что происходит на каждом шаге.
2. Найди все проблемные узлы: Sequential Scan на больших таблицах, Hash Join с большим расходом памяти, неточные оценки планировщика.
3. Для каждой проблемы: объясни причину и предложи конкретное решение.
4. Приоритизируй рекомендации по ожидаемому эффекту.
5. Если нужны индексы – приведи SQL для их создания.
6. Какие параметры конфигурации PostgreSQL могут помочь (work_mem, enable_hashjoin и т.д.).

Формат: сначала краткий вывод (3–5 предложений), затем детальный разбор по пунктам.

*****

Почему это работает: Запрос “объясни простым языком” плюс явное указание проблемных паттернов (Sequential Scan, неточные оценки) направляет нейросеть именно на те места, которые действительно влияют на производительность, а не на поверхностный разбор плана.

19. Разработка схемы для хранения документов с гибкой структурой

Проблема: Когда структура данных заранее неизвестна или часто меняется, разработчики либо создают десятки колонок “про запас”, либо хранят все в JSONB без какого-либо контроля – и оба подхода имеют серьезные последствия.

Решение: Промпт создает гибридную схему, которая сочетает строгость реляционной модели с гибкостью документного хранения.

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор баз данных с опытом проектирования гибридных схем для систем с изменяемой структурой данных”].

Спроектируй схему хранения для следующей задачи: [опишите задачу, например, “система управления заявками, где каждый тип заявки (IT-инцидент, HR-запрос, финансовое согласование) имеет разный набор полей, и новые типы добавляются раз в квартал”].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 15”] – Фиксированные поля (общие для всех типов): [перечислите, например, “id, type, status, author_id, created_at, updated_at”] – Переменные поля: [опишите, например, “зависят от типа заявки, заранее неизвестны для новых типов”] – Требования к поиску: [укажите, например, “поиск по фиксированным полям – быстрый; поиск по переменным полям – иногда нужен”] – Объем: [укажите, например, “до 5 млн заявок в год”]

Сравни подходы:

1. JSONB для переменных полей.
2. Таблица атрибутов (EAV – Entity-Attribute-Value).
3. Отдельные таблицы для каждого типа + общая таблица.

Для каждого подхода: плюсы, минусы, производительность.
Затем: рекомендованная схема с DDL, примерами запросов и стратегией индексирования JSONB.

Ограничения: схема должна поддерживать добавление новых типов без изменения DDL; поиск по фиксированным полям должен быть эффективным.

*****

Почему это работает: Требование “добавление новых типов без изменения DDL” – это конкретное ограничение, которое сразу исключает подход с отдельными таблицами как основной и направляет нейросеть к правильному гибридному решению.

20. Создание системы мониторинга состояния базы данных

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

Решение: Промпт создает набор запросов и метрик для проактивного мониторинга состояния базы данных.

Текст промпта:

*****

Ты – [укажите роль, например, “администратор баз данных PostgreSQL с опытом построения систем мониторинга для критичных продакшн-окружений”].

Создай систему мониторинга для PostgreSQL со следующими параметрами:
– Версия PostgreSQL: [укажите, например, “15”] – Критичность системы: [укажите, например, “финансовое приложение, недопустимо снижение производительности в рабочее время”] – Доступные инструменты: [укажите, например, “Zabbix + возможность писать кастомные запросы к PostgreSQL”] – Текущие проблемы: [опишите, например, “периодические всплески времени ответа, не знаем причин”]

Предоставь набор SQL-запросов для мониторинга следующих метрик:

1. Активные соединения и их состояние (idle, active, idle in transaction).
2. Долгоживущие транзакции (более 5 минут).
3. Блокировки и ожидающие запросы.
4. Самые медленные запросы (из pg_stat_statements).
5. Раздувание таблиц и индексов (bloat).
6. Отставание реплик.
7. Использование дискового пространства по таблицам.
8. Статистика попаданий в кеш (cache hit ratio).

Для каждой метрики:
– SQL-запрос для получения данных
– Пороговые значения для предупреждения и критической ошибки
– Что делать при срабатывании порога

Ограничения: запросы должны выполняться быстро (менее 1 секунды) и не нагружать систему.

*****

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

21. Написание скрипта для очистки и архивирования устаревших данных

Проблема: Данные накапливаются, таблицы растут, производительность падает – а удаление миллионов строк одним запросом блокирует таблицу и вызывает проблемы с репликацией.

Решение: Промпт создает безопасный скрипт пакетного архивирования и удаления данных без блокировки таблицы.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных с опытом написания скриптов обслуживания для высоконагруженных систем”].

Напиши скрипт архивирования и очистки данных для следующей ситуации:
– Таблица: [вставьте DDL или описание, например, “таблица logs (id BIGSERIAL, user_id BIGINT, action VARCHAR(100), details JSONB, created_at TIMESTAMP) – 200 млн строк, ежедневный прирост 500 тысяч”] – Правило архивирования: [укажите, например, “данные старше 1 года перемещать в таблицу logs_archive, данные старше 3 лет – удалять из архива”] – СУБД: [укажите, например, “PostgreSQL 15”] – Требования к скрипту: [укажите, например, “работать в пакетном режиме по 10 тысяч строк, не блокировать таблицу более 100 мс за итерацию, запускаться ночью по расписанию”]

Выполни следующее:

1. Создай таблицу logs_archive с той же структурой.
2. Напиши хранимую процедуру с пакетной обработкой.
3. Добавь логирование прогресса (сколько строк обработано, сколько времени).
4. Обработку ошибок с продолжением с последней успешной позиции.
5. SQL для запуска через pg_cron (или аналог).
6. Запрос для проверки результата.

Ограничения: не использовать DELETE без WHERE с ограничением; скрипт должен корректно завершаться при ошибке без потери данных.

*****

Почему это работает: Ограничение времени блокировки (не более 100 мс за итерацию) – это конкретный параметр, который заставляет нейросеть реализовать правильную пакетную обработку с паузами, а не просто написать DELETE с LIMIT.

22. Разработка стратегии шардирования данных

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

Решение: Промпт помогает выбрать стратегию шардирования и спроектировать ее реализацию с учетом конкретных паттернов доступа к данным.

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор распределенных систем хранения данных с опытом проектирования шардированных баз данных”].

Разработай стратегию шардирования для следующей системы:
– Описание: [опишите, например, “мессенджер с хранением истории переписки; 50 млн пользователей, 500 млн сообщений в сутки”] – СУБД: [укажите, например, “PostgreSQL 15 с Citus”] – Текущая проблема: [опишите, например, “один сервер перегружен, вертикальное масштабирование нецелесообразно”] – Паттерны доступа: [опишите, например, “99% запросов – переписка конкретного пользователя или конкретного чата; кросс-пользовательские запросы – редкость (аналитика)”]

Ответь на следующие вопросы:

1. Какой ключ шардирования выбрать и почему (по user_id, по chat_id, по хешу)?
2. Сколько шардов создать изначально и как планировать рост?
3. Как обрабатывать запросы, затрагивающие несколько шардов?
4. Как реализовать ребалансировку шардов без простоя?
5. Какие операции станут невозможными или сложными после шардирования?
6. Схема таблиц с учетом шардирования.

Ограничения: решение должно поддерживать добавление шардов без остановки системы; избегать горячих шардов.

*****

Почему это работает: Явный вопрос “какие операции станут невозможными” – это то, что обычно умалчивается в описаниях шардирования. Нейросеть вынуждена честно описать ограничения, что позволяет принять взвешенное решение.

23. Написание функции для валидации данных в базе

Проблема: Проверки данных в приложении – хорошо, но если данные попадают в базу из разных источников (API, импорт, скрипты), то без валидации на уровне базы данных гарантировать целостность невозможно.

Решение: Промпт создает набор функций и ограничений для комплексной валидации данных на уровне базы данных.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных PostgreSQL с опытом реализации бизнес-правил на уровне базы данных”].

Реализуй валидацию данных для следующей таблицы: [вставьте DDL или описание, например, “таблица employees (id, full_name, email, phone, birth_date, hire_date, salary, department_id, manager_id, status)”].

Правила валидации:
[перечислите правила, например:
“1. email – валидный формат, уникальный в рамках компании
2. phone – российский формат (+7XXXXXXXXXX или 8XXXXXXXXXX)
3. birth_date – сотрудник должен быть старше 16 лет
4. hire_date – не раньше birth_date + 16 лет, не позже текущей даты
5. salary – положительное число, не более 10 млн рублей
6. manager_id – должен ссылаться на сотрудника того же или вышестоящего отдела
7. Сотрудник не может быть своим собственным руководителем”]

СУБД: [укажите, например, “PostgreSQL 15”].

Выполни следующее:

1. Для каждого правила: реализовать как CHECK-ограничение, CONSTRAINT или триггер – с обоснованием выбора.
2. Функции-помощники для сложных проверок (например, валидация телефона через регулярное выражение).
3. Информативные сообщения об ошибках для каждого нарушения.
4. Тестовые запросы, проверяющие каждое правило.

Ограничения: валидация не должна значительно замедлять INSERT/UPDATE; сложные проверки – только там, где CHECK недостаточно.

*****

Почему это работает: Требование обоснования выбора между CHECK, CONSTRAINT и триггером заставляет нейросеть применить правильный инструмент для каждого правила, а не использовать триггеры для всего – что является распространенной ошибкой.

24. Проектирование системы управления версиями схемы

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

Решение: Промпт создает систему управления изменениями схемы с возможностью применения и отката миграций.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных с опытом внедрения процессов управления изменениями схемы в командах от 5 разработчиков”].

Разработай систему управления версиями схемы базы данных для следующей ситуации:
– Команда: [опишите, например, “5 разработчиков, каждый может вносить изменения в схему”] – Окружения: [перечислите, например, “разработка, тестирование, предпродакшн, продакшн”] – СУБД: [укажите, например, “PostgreSQL 15”] – Текущая ситуация: [опишите, например, “нет никакой системы, изменения вносятся вручную, часто расхождения между окружениями”] – Инструменты: [укажите, например, “Liquibase” или “только SQL-скрипты без внешних инструментов”]

Предоставь:

1. Структуру папок и файлов для миграций.
2. Соглашение об именовании файлов миграций.
3. Таблицу для отслеживания примененных миграций (если без внешних инструментов).
4. Шаблон файла миграции: секция применения + секция отката.
5. Скрипт для применения новых миграций.
6. Скрипт для отката последней миграции.
7. Процесс работы с миграциями в команде: кто создает, как согласовывает, как применяет.

Ограничения: решение должно работать без платных инструментов; миграции должны быть атомарными (применяются полностью или не применяются совсем).

*****

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

25. Анализ и нормализация существующей схемы

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

Решение: Промпт проводит систематический анализ схемы на нарушения нормальных форм и создает план нормализации.

Текст промпта:

*****

Ты – [укажите роль, например, “архитектор баз данных с глубоким знанием теории реляционных баз данных и практическим опытом нормализации схем”].

Проанализируй следующую схему на соответствие нормальным формам: [вставьте DDL всех таблиц или их описание].

Контекст:
– Текущие проблемы (если известны): [опишите, например, “при изменении адреса клиента нужно обновлять его в нескольких местах; иногда данные расходятся”] – Допустимые компромиссы: [укажите, например, “денормализация допустима для полей, которые используются только для чтения в аналитике”] – СУБД: [укажите, например, “PostgreSQL 15”]

Выполни следующее:

1. Проверь схему на соответствие 1НФ, 2НФ, 3НФ, НФБК.
2. Для каждого нарушения: укажи таблицу, проблемное поле, тип нарушения и конкретный пример аномалии, к которой оно приводит.
3. Предложи нормализованную схему с DDL.
4. Укажи, какие нарушения можно оставить намеренно (денормализация) и почему.
5. Оцени влияние нормализации на производительность запросов.
6. Приведи план миграции от текущей схемы к нормализованной.

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

*****

Почему это работает: Запрос конкретного примера аномалии для каждого нарушения – это ключевой момент. Абстрактное “нарушение 2НФ” непонятно, а “при изменении названия города нужно обновить 50 тысяч строк” – понятно сразу.

26. Создание системы контроля доступа к данным

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

Решение: Промпт создает продуманную систему ролей и прав доступа с принципом минимальных привилегий.

Текст промпта:

*****

Ты – [укажите роль, например, “администратор баз данных с опытом проектирования систем контроля доступа для приложений с требованиями к безопасности данных”].

Разработай систему управления доступом к базе данных для следующей ситуации:
– Описание системы: [опишите, например, “медицинская информационная система с данными пациентов”] – СУБД: [укажите, например, “PostgreSQL 15”] – Роли пользователей: [перечислите, например, “врач, медсестра, регистратор, аналитик, разработчик, администратор БД, приложение (API)”] – Чувствительные данные: [укажите, например, “диагнозы, назначения, результаты анализов – только для медперсонала; персональные данные – ограниченный доступ”] – Требования регулятора: [укажите, например, “соответствие 152-ФЗ о персональных данных”]

Выполни следующее:

1. Матрица доступа: роль × таблица × операция (SELECT/INSERT/UPDATE/DELETE).
2. SQL для создания ролей PostgreSQL и назначения прав.
3. Реализация row-level security (RLS) для случаев, когда врач должен видеть только своих пациентов.
4. Как ограничить доступ к отдельным столбцам (персональные данные).
5. Аудит доступа: как логировать, кто и когда обращался к чувствительным данным.
6. Процедура выдачи и отзыва доступа.

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

*****

Почему это работает: Указание конкретного регуляторного требования (152-ФЗ) и принципа row-level security задает нейросети правильный уровень детализации – она не ограничится базовым GRANT, а создаст реальную систему контроля доступа.

27. Диагностика и исправление проблем с целостностью данных

Проблема: Нарушения целостности данных накапливаются незаметно – “сиротские” записи без родителей, дубликаты там, где их быть не должно, противоречивые состояния – и обнаруживаются только когда приложение начинает вести себя странно.

Решение: Промпт создает набор диагностических запросов и скриптов исправления для систематической проверки и восстановления целостности данных.

Текст промпта:

*****

Ты – [укажите роль, например, “разработчик баз данных с опытом диагностики и восстановления целостности данных в продакшн-системах”].

Разработай систему диагностики и исправления целостности данных для следующей схемы: [вставьте DDL всех таблиц или их описание].

Известные проблемы (если есть): [опишите, например, “после миграции данных обнаружены заказы без клиентов; подозрение на дубликаты в таблице products”].

Контекст:
– СУБД: [укажите, например, “PostgreSQL 15”] – Возможность простоя: [укажите, например, “только ночное окно 2 часа”] – Объем данных: [укажите, например, “orders – 5 млн строк, clients – 300 тысяч строк”]

Выполни следующее:

1. Набор диагностических запросов для проверки:
   – Нарушений ссылочной целостности (записи без родителей)
   – Дубликатов по бизнес-ключам
   – Противоречивых состояний (например, завершенный заказ без даты завершения)
   – Нулевых значений в обязательных полях
2. Для каждой проблемы: запрос для подсчета масштаба нарушений.
3. Скрипты исправления с разделением на: безопасное автоматическое исправление и требующее ручной проверки.
4. Как добавить ограничения, предотвращающие повторное возникновение проблем.
5. Скрипт регулярной проверки целостности (запускать еженедельно).

Ограничения: скрипты исправления должны быть транзакционными; перед исправлением создавать резервную копию затронутых данных.

*****

Почему это работает: Разделение исправлений на “безопасные автоматические” и “требующие ручной проверки” – это принципиально важный момент. Автоматическое исправление всего подряд в продакшн-базе – это верный путь к новым проблемам, и правильно составленный запрос к нейросети это учитывает.

Типичные ошибки при работе с нейросетью в задачах разработки баз данных

1. Отправлять запрос без структуры таблиц и ожидать рабочий SQL. Нейросеть придумает названия полей и таблиц из воздуха, и полученный запрос не будет иметь никакого отношения к реальной схеме.
2. Не указывать версию и тип СУБД. Синтаксис, доступные функции и поведение оптимизатора существенно различаются между PostgreSQL 12 и PostgreSQL 15, между MySQL и PostgreSQL – получить неприменимый код очень легко.
3. Просить оптимизировать запрос без объема таблиц. Рекомендации по оптимизации принципиально разные для таблицы из 10 тысяч строк и из 100 миллионов – без этого контекста советы будут бесполезны или вредны.
4. Принимать сгенерированный DDL без проверки ограничений. Нейросеть часто пропускает NOT NULL там, где он нужен, или создает внешние ключи без индексов на дочерней таблице – это незаметно, пока не станет проблемой.
5. Запрашивать скрипт миграции без указания требований к простою. Скрипт, который блокирует таблицу на 20 минут, технически правильный – но на продакшн-системе с пользователями это катастрофа, о которой нейросеть не предупредит без явного вопроса.
6. Игнорировать сгенерированные хранимые процедуры без проверки обработки ошибок. Нейросеть нередко пишет процедуры без блока EXCEPTION или с неполным откатом транзакции – такой код молча теряет данные при сбое.
7. Просить нейросеть выбрать архитектуру без описания паттернов доступа к данным. Выбор между нормализованной схемой, денормализацией, партиционированием или шардированием полностью определяется тем, как данные читаются и пишутся – без этого нейросеть выберет наугад.
8. Копировать сгенерированные индексы без понимания их влияния на запись. Каждый индекс замедляет INSERT и UPDATE – нейросеть создаст столько индексов, сколько попросят, не предупреждая о цене для операций записи.
9. Не проверять сгенерированный код на SQL-инъекции в динамических запросах. Если нейросеть использует конкатенацию строк для построения динамического SQL в хранимой процедуре – это уязвимость, которая не бросается в глаза при беглом просмотре.

Сравнение слабых и сильных запросов к нейросети для задач разработки баз данных

Задача	Слабый запрос	Сильный запрос	Почему слабый не работает
Оптимизация запроса	“Оптимизируй этот SQL-запрос”	“Оптимизируй запрос для PostgreSQL 15, таблица orders – 8 млн строк, текущее время – 14 секунд, вот вывод EXPLAIN ANALYZE”	Без объема таблицы и плана выполнения нейросеть угадывает проблему
Проектирование схемы	“Создай схему БД для интернет-магазина”	“Создай схему для интернет-магазина на PostgreSQL 15: до 500 тысяч товаров, мультивалютность, нужны индексы для поиска по категории и цене, DDL с комментариями”	Без параметров получается универсальная схема из учебника, не подходящая ни для чего конкретного
Написание триггера	“Напиши триггер для аудита таблицы”	“Напиши триггер аудита для таблицы employees в PostgreSQL: логировать INSERT/UPDATE/DELETE, сохранять старые и новые значения в таблицу audit_log, не логировать изменения поля updated_at”	Без указания исключений триггер будет писать тысячи бесполезных записей
Индексирование	“Добавь индексы для ускорения запросов”	“Предложи индексы для таблицы transactions (50 млн строк, PostgreSQL 15): 90% запросов – по user_id за период, 10% – агрегация по merchant_id; учти нагрузку на запись 200 тысяч строк в сутки”	Без паттернов использования нейросеть добавит индексы на все поля в WHERE
Миграция данных	“Напиши скрипт миграции данных”	“Напиши скрипт миграции 2 млн строк из таблицы users в таблицу clients (PostgreSQL 14), допустимый простой – 30 минут, поле name нужно разбить на first_name/last_name, скрипт должен быть идемпотентным”	Без ограничений по простою и особых условий скрипт заблокирует таблицу и не обработает нестандартные данные
Резервное копирование	“Как настроить бэкапы PostgreSQL?”	“Разработай стратегию резервного копирования PostgreSQL 15: база 800 ГБ, допустимая потеря данных – 1 час, время восстановления – 4 часа, хранение в Яндекс.Облако, требования 152-ФЗ”	Без требований к восстановлению нейросеть предложит простой pg_dump раз в сутки
Полнотекстовый поиск	“Реализуй поиск по таблице товаров”	“Реализуй полнотекстовый поиск по таблице products (500 тысяч строк, PostgreSQL 15): русский язык, поля name (высокий приоритет) и description, до 100 запросов в секунду, ранжирование по релевантности, pg_trgm для поиска по части слова”	Без языка и весов полей получится поиск без морфологии и с одинаковым ранжированием всех полей

Неочевидные советы по работе с нейросетью в задачах разработки баз данных

1. Передавайте нейросети вывод EXPLAIN ANALYZE целиком, даже если он выглядит громоздким. Именно в этом выводе содержится реальная картина выполнения запроса – без него нейросеть будет угадывать узкие места, а с ним – точно укажет на проблемный узел.
2. Просите нейросеть сначала перечислить ограничения предложенного решения, прежде чем принимать его. Каждая архитектурная рекомендация имеет подводные камни – шардирование ломает транзакционность, партиционирование усложняет некоторые запросы, и нейросеть расскажет об этом только если спросить напрямую.
3. Давайте нейросети реальные примеры “плохих” данных при запросе скриптов миграции или валидации. Фраза “поле created_date содержит даты в разных форматах” – слишком абстрактна; “встречаются форматы 01.01.2023, 2023-01-01 и January 1, 2023” – дает конкретику, которая появится в коде обработки.
4. При генерации схемы просите нейросеть указать, какие решения она приняла по умолчанию и почему. Нейросеть часто выбирает тип данных, длину строки или стратегию индексирования неявно – понимание этих решений позволяет скорректировать их под конкретную задачу до реализации, а не после.
5. Используйте нейросеть для генерации контрпримеров к собственным решениям. Запрос “найди слабые места в этой схеме” или “как эта хранимая процедура может сломаться при нагрузке” часто выявляет проблемы, которые не заметны при самостоятельном просмотре кода.
6. Просите нейросеть генерировать тесты целостности данных сразу вместе со скриптами изменения схемы. Промпты для разработчика баз данных становятся значительно полезнее, когда к каждому DDL-изменению прилагается набор проверочных запросов – это позволяет убедиться в корректности результата без ручного разбора данных.
7. При работе с большими схемами передавайте нейросети только релевантные таблицы, а не всю схему целиком. Контекстное окно не бесконечно, и при передаче 50 таблиц для задачи, касающейся трех из них, качество ответа снижается – нейросеть “размывает” внимание по всей схеме.