SQL и NoSQL под контролем: 10 промтов, которые заменят DBA, если вы разработчик

Когда я впервые столкнулся с задачей переноса легаси-базы с MongoDB на PostgreSQL, мне казалось, что это займёт пару дней. В итоге проект растянулся на две недели, а большая часть времени ушла не на сам перенос данных, а на переписывание запросов и оптимизацию схемы. Именно тогда я понял, что даже опытному разработчику не хватает системного подхода к работе с базами данных. Эта подборка — результат моего опыта и анализа лучших практик, которые я собрал из официальной документации и реальных кейсов. Здесь вы найдёте промты, которые помогут вам проектировать схемы, оптимизировать запросы и мигрировать данные без боли, используя возможности современных LLM как мощного ассистента.

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

Базовые промты: проектирование и первые шаги

Промт 1: Генерация схемы PostgreSQL по описанию требований

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

Промт:

Ты — опытный архитектор баз данных. Спроектируй схему PostgreSQL для системы управления задачами (аналог Trello). Учти следующие требования: пользователи могут создавать доски, списки и карточки; карточки могут иметь метки, чек-листы и комментарии; нужна поддержка истории изменений. Предложи структуру таблиц, типы данных, индексы и ограничения внешних ключей. Для каждой таблицы укажи назначение и примеры запросов.

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

Нейросеть сгенерирует SQL-код, который можно сразу выполнить. Например:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE boards (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    title VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);
-- ... остальные таблицы

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

Промт 2: Проектирование документной модели в MongoDB

Задача: Спроектировать схему MongoDB для интернет-магазина, учитывая паттерны доступа к данным.

Промт:

Ты — эксперт по MongoDB. Спроектируй документную модель для интернет-магазина, где товары имеют категории, бренды, характеристики и отзывы. Учитывай, что чаще всего пользователи просматривают каталог, ищут товары по фильтрам и читают отзывы. Предложи структуру коллекций, примеры документов и объясни, почему выбран тот или иной паттерн (встраивание или ссылки). Приведи примеры агрегационных запросов для вывода товаров с фильтрами.

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

AI предложит модель с коллекциями products, categories, reviews и, возможно, brands. Для каждого документа будет пример, например:

{
  "_id": ObjectId("..."),
  "name": "Смартфон X",
  "category_id": ObjectId("..."),
  "brand": "Samsung",
  "price": 59999,
  "attributes": { "color": "black", "storage": "128GB" },
  "reviews": [
    { "user_id": ObjectId("..."), "rating": 4.5, "text": "Отличный телефон" }
  ]
}

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

Промт 3: Создание миграции данных с помощью скриптов

Задача: Сгенерировать скрипт миграции из MySQL в PostgreSQL, учитывая различия в типах данных.

Промт:

Ты — разработчик, который переносит базу данных из MySQL в PostgreSQL. Напиши Python-скрипт с использованием SQLAlchemy, который переносит данные из таблицы `users` (MySQL) в новую таблицу `users` (PostgreSQL). Учти, что в MySQL поле `id` имеет тип INT AUTO_INCREMENT, а в PostgreSQL мы хотим использовать SERIAL. Также поле `created_at` в MySQL имеет тип TIMESTAMP, а в PostgreSQL мы хотим TIMESTAMPTZ. Обработай возможные ошибки и выведи лог переноса.

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

Скрипт на Python с подключением к обеим базам, извлечением данных, трансформацией и вставкой. Например:

from sqlalchemy import create_engine, MetaData, Table, select, insert

src_engine = create_engine('mysql+pymysql://user:pass@localhost/source_db')
dst_engine = create_engine('postgresql+psycopg2://user:pass@localhost/dest_db')

src_meta = MetaData()
src_users = Table('users', src_meta, autoload_with=src_engine)
dst_meta = MetaData()
dst_users = Table('users', dst_meta, autoload_with=dst_engine)

with src_engine.connect() as src_conn, dst_engine.connect() as dst_conn:
    result = src_conn.execute(select(src_users))
    for row in result:
        dst_conn.execute(insert(dst_users).values(
            id=row.id,
            email=row.email,
            created_at=row.created_at
        ))
    dst_conn.commit()

AI также добавит логирование и обработку ошибок.

Продвинутые промты: оптимизация запросов и индексов

Промт 4: Анализ и оптимизация медленных запросов в PostgreSQL

Задача: Найти и исправить медленные запросы в PostgreSQL, используя EXPLAIN ANALYZE.

Промт:

Ты — опытный DBA. Вот результат EXPLAIN ANALYZE для запроса, который выполняется 5 секунд. Проанализируй его и предложи, какие индексы или изменения в запросе могут ускорить выполнение. Запрос: SELECT * FROM orders WHERE user_id = 123 AND status = 'pending' ORDER BY created_at DESC LIMIT 10; Вот план:
[вставьте вывод EXPLAIN ANALYZE]
Предложи конкретные действия: какие индексы создать, нужно ли переписать запрос, какие параметры конфигурации PostgreSQL можно подстроить.

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

AI проанализирует план и скажет, что используется Seq Scan, и предложит создать составной индекс на (user_id, status, created_at DESC). Объяснит, почему такой индекс полезен, и покажет SQL для его создания. Также может посоветовать изменить work_mem для сортировок. Важно, что AI должен видеть реальный план, поэтому в промт нужно вставить вывод EXPLAIN ANALYZE.

Промт 5: Оптимизация агрегационных запросов в MongoDB

Задача: Улучшить производительность пайплайна агрегации в MongoDB.

Промт:

Ты — специалист по MongoDB. У меня есть коллекция `sales` с документами:
{ "product": "A", "amount": 100, "date": ISODate("2026-01-01"), "region": "EU" }
Мне нужно получить сумму продаж по продуктам за последний месяц, но запрос работает медленно. Вот текущий пайплайн:
[вставьте пайплайн]
Посоветуй, как его оптимизировать: какие индексы создать, как переставить стадии, можно ли использовать $match раньше. Приведи пример оптимизированного пайплайна и объясни, почему он быстрее.

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

AI предложит добавить индекс на { date: 1, product: 1 }, а затем переставить стадии, чтобы $match по дате шёл первым. Приведёт оптимизированный пайплайн и объяснит, что использование $match на ранней стадии уменьшает количество документов, проходящих через последующие стадии, что экономит память и время.

Промт 6: Генерация сложных SQL-запросов с подзапросами и CTE

Задача: Написать запрос, который выводит топ-5 пользователей по сумме заказов за последний квартал, с использованием CTE. Нейросеть должна объяснить логику.

Промт:

Ты — эксперт по SQL. Напиши запрос PostgreSQL, который выводит топ-5 пользователей по сумме заказов за последний квартал (от текущей даты). Используй оконные функции или CTE. Покажи, как можно получить тот же результат с помощью подзапроса, и объясни разницу в производительности. Также добавь, какие индексы ускорили бы этот запрос.

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

AI сгенерирует запрос с CTE:

WITH recent_orders AS (
    SELECT user_id, SUM(amount) as total
    FROM orders
    WHERE created_at >= date_trunc('quarter', CURRENT_DATE) - interval '3 months'
    GROUP BY user_id
)
SELECT u.id, u.email, r.total
FROM users u
JOIN recent_orders r ON u.id = r.user_id
ORDER BY r.total DESC
LIMIT 5;

И объяснит, что CTE выполняется один раз и может быть материализован, а подзапрос может быть выполнен для каждой строки, что менее эффективно. Также предложит создать индекс на orders(created_at) и orders(user_id, created_at).

Экспертные промты: тонкая настройка и нестандартные решения

Промт 7: Партиционирование таблиц в PostgreSQL для больших данных

Задача: Спроектировать партиционирование для таблицы events с миллионами записей.

Промт:

Ты — архитектор БД. У меня есть таблица events (id, event_type, created_at, payload JSONB), которая растёт на 1 млн строк в месяц. Нужно реализовать партиционирование по дате. Опиши, как создать секции по месяцам, какие ограничения нужны, как обеспечить автоматическое создание секций. Также расскажи, как партиционирование повлияет на запросы и какие есть подводные камни.

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

AI предложит декларативное партиционирование с PARTITION BY RANGE (created_at), создаст секции на текущий и следующий месяц, объяснит, как использовать pg_partman для автоматического создания секций, и предупредит о том, что индексы нужно создавать на каждой секции отдельно. Приведёт SQL-код для создания партиционированной таблицы.

Промт 8: Шардирование MongoDB и выбор ключа шардирования

Задача: Определить оптимальный ключ шардирования для коллекции с учётом паттернов доступа.

Промт:

Ты — эксперт по MongoDB. У меня есть коллекция `user_activity` с документами:
{ "user_id": ObjectId, "action": "click", "timestamp": ISODate, "metadata": {...} }
Коллекция очень большая, и мы планируем шардирование. Помоги выбрать ключ шардирования. Учитывай, что чаще всего мы запрашиваем данные по user_id за определённый период. Объясни, как выбор ключа влияет на распределение данных и производительность. Предложи несколько вариантов и обоснуй лучший.

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

AI проанализирует паттерны доступа и предложит использовать user_id в качестве ключа, так как запросы фильтруют по нему. Объяснит, что это обеспечит равномерное распределение, но может привести к горячим точкам для популярных пользователей. Как альтернативу предложит составной ключ { user_id: 1, timestamp: 1 } и объяснит, как это сгладит нагрузку.

Промт 9: Сравнение производительности PostgreSQL и MongoDB для конкретного сценария

Задача: Получить аналитическое сравнение для выбора СУБД под новый проект.

Промт:

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

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

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

Промт 10: Генерация тестовых данных для нагрузочного тестирования

Задача: Создать скрипт для генерации большого объёма тестовых данных в PostgreSQL.

Промт:

Ты — тестировщик БД. Напиши SQL-скрипт или функцию на PL/pgSQL, которая генерирует 1 миллион записей в таблице `orders` с реалистичными данными: случайные user_id (от 1 до 10000), случайная сумма от 10 до 1000, случайная дата за последний год. Используй генератор случайных чисел. Обеспечь выполнение за разумное время.

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

AI предложит:

INSERT INTO orders (user_id, amount, created_at)
SELECT floor(random() * 10000 + 1)::int,
       round((random() * 990 + 10)::numeric, 2),
       now() - (random() * interval '365 days')
FROM generate_series(1, 1000000);

И пояснит, как использовать generate_series для массовой вставки, и что это займёт несколько секунд.

Промт 11: Анализ и оптимизация индексов в PostgreSQL с помощью pg_stat_statements

Задача: Использовать статистику pg_stat_statements для поиска неиспользуемых индексов.

Промт:

Ты — профессиональный DBA. У меня включён pg_stat_statements. Вот вывод запроса, который показывает топ-10 самых медленных запросов:
[вставьте вывод]
Проанализируй эти запросы и предложи, какие индексы можно создать или удалить, чтобы улучшить производительность. Учти, что у нас есть таблицы: users, orders, products. Обоснуй свои рекомендации.

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

AI изучит статистику, найдёт запросы с высоким временем выполнения и предложит создать недостающие индексы, а также заметит, какие индексы не используются и могут быть удалены для экономии места. Приведёт SQL для создания/удаления индексов.

Промт 12: Миграция схемы MongoDB в PostgreSQL с сохранением связей

Задача: Спроектировать реляционную схему для данных, хранящихся в MongoDB, с учётом встроенных документов.

Промт:

Ты — специалист по миграции. У меня есть коллекция `products` в MongoDB, где каждый документ имеет встроенный массив `reviews`. Я хочу перенести данные в PostgreSQL, сохранив связь между товарами и отзывами. Предложи структуру таблиц, типы данных, внешние ключи и объясни, как преобразовать встроенные документы в связанные таблицы. Напиши SQL для создания таблиц и пример запроса для получения товаров с отзывами.

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

AI предложит таблицы products, reviews, где reviews имеет внешний ключ на products. Покажет SQL:

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC(10,2)
);

CREATE TABLE reviews (
    id SERIAL PRIMARY KEY,
    product_id INT NOT NULL REFERENCES products(id) ON DELETE CASCADE,
    user_id INT,
    rating INT CHECK (rating BETWEEN 1 AND 5),
    text TEXT
);

И пример запроса с JOIN.

Что в итоге?

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

Если вы хотите углубиться в тему и научиться применять такие промты системно, обратите внимание на наш курс по работе с базами данных и AI-ассистентами. Вы узнаете, как выстраивать эффективные процессы проектирования и оптимизации с помощью AI, экономя часы рутинной работы.