Промпты для баз данных. 22 готовых примера для ChatGPT, DeepSeek, Gemini и других ИИ

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

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

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

• Главные ошибки, из-за которых вы получаете мусор вместо кода.
• Анатомию идеального промпта, который поймет любая модель.
• Принципы, которые помогут вам создавать свои запросы для любой задачи.
• И, конечно, 22 готовых полноформатных промпта для самых разных ситуаций.

Почему ваши промпты не работают: разбираем типичные ошибки

Ошибка №1: Отсутствие контекста

Самая распространенная и болезненная ошибка — это бросать в ИИ задачу, вырванную из контекста. Запрос вроде “напиши SQL для выбора пользователей” обречен на провал. Почему? Потому что нейросеть не знает ответов на десятки скрытых вопросов.

• Из какой таблицы выбирать? Как она называется?
• Какие поля есть в этой таблице (`id`, `user_id`, `name`, `login`)?
• Какой диалект SQL вам нужен? PostgreSQL, MySQL, MS SQL, SQLite? У них разный синтаксис.
• Есть ли какие-то условия? Например, выбрать только активных пользователей.

В результате такого запроса вы получаете “сферический SQL в вакууме” — синтаксически верный, но абсолютно неприменимый к вашему проекту код. Это приводит к пустой трате времени на доработку и исправление, а ведь этого можно было легко избежать.

Ошибка №2: Двусмысленность и расплывчатость

Нейросеть не умеет читать мысли. Фразы “сделай хорошую структуру” или “оптимизируй запрос” для нее — пустой звук. Что такое “хорошая” структура в вашем понимании? Оптимизировать для скорости чтения? Для скорости записи? Для экономии места на диске?

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

Практический пример провала

Вот типичный пример плохого запроса и его печального результата.

CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    price DECIMAL(10, 2)
);

Формально, это таблица для товаров. Но можно ли ее использовать в реальном проекте? Нет. Где артикул, описание, количество на складе, категории, связь с поставщиками? Этот результат бесполезен, потому что исходный запрос был слишком расплывчатым. ИИ дал самый базовый ответ, какой только смог придумать.

Ошибка №3: Игнорирование цели и ограничений

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

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

Обратите внимание

Всегда указывайте диалект SQL (например, PostgreSQL 15, MySQL 8.0). Это одна из самых частых и досадных ошибок. Синтаксис функций, типы данных и даже операторы могут отличаться. Если не указать диалект, ИИ может выдать код для другой СУБД, и вы потратите время на поиск синтаксических ошибок, которых могло и не быть.

Анатомия идеального промпта: как составить эффективные промпты для баз данных

Чтобы избежать перечисленных выше проблем, нужно подходить к составлению промпта системно. Эффективный запрос — это не одно предложение, а скорее небольшое техническое задание. Он состоит из нескольких обязательных блоков, которые вместе дают нейросети полную картину мира.

Ключевые компоненты успешного промпта

1. Роль (Role): Укажите, кем должна быть нейросеть. Это настраивает ее на нужный лад. Например: “Ты — опытный DBA (администратор баз данных) со специализацией на PostgreSQL”. Это сразу повышает качество ответа.
2. Контекст (Context): Опишите проект, предметную область и существующие элементы. “Я разрабатываю систему управления заказами для ресторана. Уже есть таблица `users` и `menu_items`…”.
3. Задача (Task): Четко и однозначно сформулируйте, что нужно сделать. “Напиши SQL-запрос для создания таблицы `orders` (заказы)”.
4. Детали и требования (Details & Requirements): Это самая важная часть. Здесь вы перечисляете все детали: поля, типы данных, связи, ограничения. “Таблица должна содержать поля: `id` (первичный ключ, автоинкремент), `user_id` (внешний ключ к `users.id`)…”.
5. Формат вывода (Output Format): Укажите, в каком виде вы хотите получить ответ. “Предоставь только SQL-код без лишних объяснений” или “Сгенерируй код и добавь комментарии к каждому полю”.
6. Ограничения и цель (Constraints & Goal): Если есть особые условия, их нужно озвучить. “Структура должна быть оптимизирована для быстрых выборок. Используй синтаксис PostgreSQL 14”.
7. Примеры (Examples): Для сложных задач полезно дать пример. “Например, если в таблице `orders` есть запись, то в `order_items` должно быть несколько связанных записей”.

Собирая все эти части вместе, вы превращаете свой запрос из лотерейного билета в инженерный инструмент.

Пошаговая инструкция по созданию промпта

Давайте соберем хороший промпт для той же задачи с таблицей товаров.

1. Начинаем с роли: “Ты — эксперт по проектированию баз данных для e-commerce проектов, специализируешься на MySQL.”
2. Добавляем контекст: “Я создаю интернет-магазин одежды.”
3. Ставим задачу: “Сгенерируй DDL-скрипт для создания таблицы `products`.”
4. Перечисляем детали: “Таблица должна включать: `id` (BIGINT, PK, AI), `sku` (артикул, VARCHAR(100), уникальный), `name` (название, VARCHAR(255)), `description` (описание, TEXT), `price` (DECIMAL(10, 2)), `stock_quantity` (количество на складе, INT), `created_at` (TIMESTAMP, по умолчанию текущее время).”
5. Уточняем формат: “Выведи только готовый SQL-код в одном блоке.”
6. Обозначаем цель: “Структура должна быть готова к добавлению связей с таблицами категорий и брендов в будущем.”

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

Арсенал наставника: 22 готовых промпта для ваших задач

Ниже представлены 22 примера полноформатных промптов для различных задач, связанных с базами данных. Они составлены по описанным выше принципам. Вы можете использовать их как есть или адаптировать под свои нужды. Каждый промпт — это не просто команда, а мини-ТЗ для нейросети.

Категория 1: Проектирование и создание структуры

Промпт 1: Создание реляционной схемы для онлайн-школы (PostgreSQL)

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

Контекст: Я создаю платформу для онлайн-курсов. Основные сущности: Ученики, Курсы, Уроки, Преподаватели. Ученик может записаться на несколько курсов. Курс состоит из множества уроков. У каждого курса есть один преподаватель.

Задача: Спроектируй и сгенерируй DDL-скрипт на PostgreSQL 15 для создания четырех основных таблиц: `teachers`, `courses`, `lessons` и `student_enrollments` (связующая таблица между учениками и курсами).

Требования:

• `teachers`: `id`, `full_name`, `bio`, `created_at`.
• `courses`: `id`, `title`, `description`, `teacher_id` (внешний ключ к `teachers.id`).
• `lessons`: `id`, `title`, `content` (TEXT), `course_id` (внешний ключ к `courses.id`), `order_in_course` (INT для сортировки).
• `student_enrollments`: `id`, `student_id` (предполагаем, что таблица `students` уже есть), `course_id`, `enrollment_date`.
• Используй корректные типы данных (SERIAL для PK, TEXT для описаний, TIMESTAMP WITH TIME ZONE для дат).
• Добавь ограничения внешних ключей с каскадным удалением (ON DELETE CASCADE) там, где это логично (например, при удалении курса удалять его уроки).

Формат вывода: Единый блок SQL-кода с комментариями для каждой таблицы.

Промпт 2: Генерация NoSQL-схемы (MongoDB) для коллекции постов блога

Роль: Ты — эксперт по MongoDB, который понимает, когда и как использовать встраивание (embedding) и ссылки (referencing).

Контекст: Я разрабатываю блог. Основная сущность — Пост. У поста есть автор, теги и комментарии. Чтение постов — самая частая операция. Запись комментариев — тоже частая, но менее критичная по скорости.

Задача: Предложи оптимальную структуру документа для коллекции `posts` в MongoDB.

Требования:

• Документ поста должен содержать: `_id`, `title`, `content`, `author_id` (ссылка на коллекцию `users`), `tags` (массив строк), `created_at`.
• Предложи два варианта для хранения комментариев:
  1. Комментарии встраиваются как массив объектов в сам документ поста.
  2. Комментарии хранятся в отдельной коллекции `comments`, а в посте — только их количество и ссылка на них.

Формат вывода: Для каждого из двух вариантов предоставь:

1. Пример JSON-структуры документа.
2. Краткое объяснение плюсов и минусов данного подхода в контексте моего блога (производительность чтения vs. размер документа).

Промпт 3: Создание ER-диаграммы в синтаксисе Mermaid

Роль: Ты — системный аналитик, который умеет визуализировать структуру баз данных.

Контекст: У меня есть три таблицы: `authors` (`id`, `name`), `books` (`id`, `title`, `author_id`), `reviews` (`id`, `book_id`, `review_text`).

Задача: Создай код для ER-диаграммы (entity-relationship), который описывает связи между этими тремя таблицами.

Требования:

• Используй синтаксис Mermaid.js.
• Покажи связи: один автор может иметь много книг (one-to-many), одна книга может иметь много обзоров (one-to-many).
• Четко укажи типы связей на диаграмме.

Формат вывода: Только код в блоке `erDiagram` для Mermaid.

Промпт 4: Изменение существующей таблицы (ALTER TABLE)

Роль: Ты — DBA, который выполняет миграции баз данных.

Контекст: У меня есть таблица `users` в PostgreSQL со следующей структурой: `id`, `username`, `password_hash`, `email`.

Задача: Сгенерируй SQL-скрипт `ALTER TABLE` для следующих изменений:

Требования:

1. Добавить столбец `last_login` с типом `TIMESTAMP WITH TIME ZONE`, который может быть NULL.
2. Добавить столбец `is_active` с типом `BOOLEAN`, со значением по умолчанию `true` и ограничением `NOT NULL`.
3. Переименовать столбец `username` в `login`.
4. Добавить ограничение `UNIQUE` для столбца `email`.

Формат вывода: Последовательность из четырех `ALTER TABLE` запросов.

Промпт 5: Генерация скрипта для создания индексов

Роль: Ты — специалист по оптимизации производительности баз данных.

Контекст: У меня есть таблица `payments` в MySQL с полями `id`, `user_id`, `amount`, `currency`, `status`, `created_at`. Таблица содержит миллионы записей.

Задача: Напиши скрипт для создания индексов, которые ускорят следующие типовые запросы:

Требования:

1. Выборка всех платежей конкретного пользователя (`WHERE user_id = ?`).
2. Выборка платежей за определенный период (`WHERE created_at BETWEEN ? AND ?`).
3. Выборка платежей с определенным статусом для аналитики (`WHERE status = ?`).
4. Создай составной индекс для частого запроса, который фильтрует по пользователю и статусу одновременно (`WHERE user_id = ? AND status = ?`).

Формат вывода: SQL-скрипт с командами `CREATE INDEX`.

Категория 2: Генерация и оптимизация запросов

Промпт 6: Написание сложного JOIN-запроса

Роль: Ты — аналитик данных, мастерски владеющий SQL.

Контекст: Есть 4 таблицы в PostgreSQL:

• `customers` (`id`, `name`)
• `orders` (`id`, `customer_id`, `order_date`)
• `order_items` (`id`, `order_id`, `product_id`, `quantity`, `price_per_item`)
• `products` (`id`, `name` AS `product_name`)

Задача: Напиши единый SQL-запрос, который для каждого покупателя (`customers.name`) выведет:

Требования:

1. Имя покупателя.
2. Общее количество его заказов.
3. Сумму всех его заказов (сумма произведений `quantity * price_per_item` по всем товарам во всех его заказах).
4. Дату его последнего заказа.
5. Результат отсортируй по общей сумме заказов по убыванию.

Формат вывода: Только SQL-запрос.

Промпт 7: Оптимизация медленного запроса (с использованием EXPLAIN)

Роль: Ты — гуру производительности PostgreSQL.

Контекст: У меня есть медленный запрос, который ищет пользователей по фрагменту email и дате регистрации. Я запустил `EXPLAIN ANALYZE` и получил следующий план:
(Здесь вы вставляете свой реальный план запроса)

Seq Scan on users (cost=0.00..15000.00 rows=1000 width=120) (actual time=0.1..500.5 ms rows=950 loops=1)
  Filter: ((email)::text ~~ '%example.com'::text AND created_at > '2023-01-01')
Planning Time: 0.2 ms
Execution Time: 501.0 ms

Задача: Проанализируй этот план выполнения и предложи улучшения для ускорения запроса.

Требования:

1. Объясни простыми словами, почему запрос работает медленно (укажи на `Seq Scan`).
2. Предложи, какой индекс (или индексы) следует создать для оптимизации. Объясни, почему именно такой. Рассмотри вариант использования `pg_trgm` для поиска по подстроке.
3. Напиши `CREATE INDEX` команду для предложенного индекса.

Формат вывода: Структурированный ответ с тремя пунктами.

Промпт 8: Запрос с оконными функциями

Роль: Ты SQL-разработчик, который обожает оконные функции.

Контекст: Есть таблица `employee_sales` с полями: `employee_id`, `department`, `sale_amount`, `sale_date`.

Задача: Напиши запрос на PostgreSQL, который для каждой продажи выведет:

Требования:

1. ID сотрудника и его отдел.
2. Сумму продажи.
3. Ранг сотрудника внутри его отдела по сумме продаж (самая большая продажа — ранг 1). Используй `DENSE_RANK()`.
4. Общую сумму продаж по всему отделу, к которому относится сотрудник.

Формат вывода: SQL-запрос с использованием оконных функций `DENSE_RANK()` и `SUM() OVER (…)`.

Промпт 9: Создание рекурсивного запроса (CTE)

Роль: Ты — специалист по иерархическим данным в SQL.

Контекст: Есть таблица `employees` со структурой `id`, `name`, `manager_id` (ссылается на `employees.id`). `manager_id` для генерального директора равен NULL.

Задача: Напиши рекурсивный запрос с использованием Common Table Expressions (CTE) в PostgreSQL, который для сотрудника с `id = 10` найдет всю его иерархию руководителей вплоть до генерального директора.

Требования:

• Запрос должен возвращать `id`, `name`, `manager_id` и уровень иерархии (level, у самого сотрудника уровень 0, у его прямого начальника — 1 и т.д.).

Формат вывода: Готовый SQL-запрос с `WITH RECURSIVE`.

Промпт 10: Запрос для полнотекстового поиска

Роль: Ты — эксперт по полнотекстовому поиску в PostgreSQL.

Контекст: Есть таблица `articles` с полями `id`, `title` (TEXT) и `body` (TEXT). Для этой таблицы уже создан FTS-индекс по полям `title` и `body` с использованием русского словаря.

Задача: Напиши SQL-запрос, который найдет все статьи, наиболее релевантные поисковой фразе “экономический кризис в России”.

Требования:

1. Используй функцию `to_tsvector` для текста и `to_tsquery` для поискового запроса.
2. Используй оператор `@@` для поиска.
3. Отсортируй результаты по релевантности, используя функцию `ts_rank`.
4. Выведи `id`, `title` и ранг релевантности для 10 самых подходящих статей.

Формат вывода: SQL-запрос.

Категория 3: Работа с данными

Промпт 11: Генерация реалистичных тестовых данных

Промпт 12: Написание INSERT-скрипта из CSV

Промпт 13: Сложный UPDATE-скрипт с условиями

Промпт 14: Скрипт для анонимизации данных

Категория 4: Администрирование и безопасность

Промпт 15: Создание хранимой процедуры

Промпт 16: Написание триггера

Промпт 17: Генерация скрипта резервного копирования

Промпт 18: Аудит прав пользователей

Категория 5: Анализ и документация

Промпт 19: Объяснение сложного SQL-запроса

Промпт 20: Генерация документации для схемы БД

Промпт 21: SQL-запрос для когортного анализа

Промпт 22: Отладка SQL-запроса с ошибкой

За гранью “копировать-вставить”: как адаптировать и исправлять

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

Пошаговая инструкция по адаптации шаблона

1. Прочитайте и поймите шаблон. Разберитесь, за что отвечает каждая его часть (роль, контекст, задача).
2. Замените контекст. Впишите названия ваших таблиц, полей, опишите специфику вашего проекта. Будьте максимально точны.
3. Скорректируйте задачу и требования. Измените поля, которые вам нужны, типы данных, условия `WHERE` и т.д.
4. Укажите ваш диалект SQL и его версию. Это избавит от 90% синтаксических ошибок.
5. Запустите и проверьте. Выполните сгенерированный код на тестовой базе данных. Проверьте не только его работоспособность, но и логику. Действительно ли он делает то, что вы хотели?

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

Часто задаваемые вопросы

Вопрос: ИИ сгенерировал код для MySQL, а мне нужен PostgreSQL. Что я сделал не так?

Скорее всего, вы забыли явно указать диалект и версию SQL в своем промпте. Нейросети обучены на огромном массиве кода, и если не задать рамки, они могут выбрать самый популярный или первый пришедший на ум вариант. Всегда добавляйте фразу вроде “Используй синтаксис PostgreSQL 15” или “Код должен быть совместим с MySQL 8.0”.

Вопрос: Сгенерированный запрос работает очень медленно. Что теперь делать?

Это классический случай, когда ИИ не хватило контекста о ваших данных. Он не знает, сколько у вас записей в таблице, каково распределение данных и какие запросы выполняются чаще всего. Чтобы решить эту проблему, создайте новый промпт (например, по шаблону 7), вставьте в него медленный запрос и результат его `EXPLAIN ANALYZE`, и попросите ИИ предложить индексы для оптимизации.

Вопрос: Нейросеть отказывается генерировать скрипт, ссылаясь на политику безопасности. Почему?

Вероятно, ваш запрос случайно задел встроенные в ИИ фильтры безопасности. Например, слова “удалить всех пользователей” или “изменить пароли” могут быть восприняты как потенциально вредоносная команда. Попробуйте переформулировать задачу. Вместо “скрипт для удаления пользователей” напишите “скрипт для архивации пользователей со статусом ‘inactive’ путем их перемещения в таблицу `archived_users`”. Чем конкретнее и безобиднее звучит ваша цель, тем охотнее ИИ поможет.

Финальный чек-лист перед отправкой промпта

Прежде чем нажать “Enter”, пробегитесь по этому короткому списку. Он поможет избежать досадных ошибок и значительно повысит шансы на получение качественного результата с первого раза.

1. Роль задана? (Например, “Ты — DBA эксперт по MySQL”).
2. Контекст описан? (Проект, существующие таблицы, цель).
3. Диалект и версия SQL указаны? (“Используй PostgreSQL 14”).
4. Задача сформулирована однозначно? (Не “сделай хорошо”, а “создай таблицу с полями X, Y, Z”).
5. Детали (поля, типы, связи) перечислены? (Чем больше деталей, тем лучше).
6. Формат вывода определен? (“Только SQL-код”, “Код с комментариями”).
7. Проверили на отсутствие реальных чувствительных данных? (Никаких настоящих паролей, ключей API и т.д.).

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

Ключевые выводы

• ИИ — это инструмент, а не волшебник. Качество результата напрямую зависит от качества вашего запроса.
• Контекст решает все. Без описания проекта, таблиц и диалекта SQL вы получите бесполезный код.
• Структурируйте свои промпты. Используйте блоки “Роль”, “Контекст”, “Задача”, “Требования” и “Формат вывода”.
• Не доверяйте слепо. Всегда проверяйте, тестируйте и адаптируйте сгенерированный код.
• Итерируйте. Не получился идеальный ответ с первого раза? Дополните промпт и попробуйте снова.

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