SQL, PostgreSQL и MongoDB: 10 промтов, которые превратят LLM в вашего DBA

Представьте: вместо того чтобы часами писать сложные JOIN, проектировать схему БД или искать медленный запрос, вы просто описываете задачу на естественном языке — и получаете готовый, оптимизированный код. Звучит как фантастика? А вот и нет. Современные LLM (вроде GPT-4, Claude 3.5 Sonnet или YandexGPT) отлично справляются с рутиной баз данных, если правильно составить промт. В этой статье я собрал 10 проверенных промтов, которые реально экономят часы работы. Никакой воды — только практика, примеры и разбор, как это работает.

Почему это важно? По данным Stack Overflow Developer Survey 2024, PostgreSQL и MongoDB входят в топ-5 самых используемых СУБД, а SQL остается самым востребованным языком для аналитики. При этом разработчики тратят до 30% рабочего времени на оптимизацию запросов и отладку. LLM могут взять на себя значительную часть этой рутины, но только если вы умеете правильно ставить задачу. Ниже — мой личный набор промтов, отточенный на реальных проектах.

1. Базовый SQL: генерация запроса по описанию

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

Промт:

Напиши SQL-запрос для PostgreSQL, который выводит имена клиентов и сумму их заказов за последний месяц. Таблицы: customers (id, name), orders (id, customer_id, amount, created_at). Учитывай только оплаченные заказы (status = 'paid'). Отсортируй по сумме убыванию. Добавь комментарии к каждой части запроса.

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

-- Выбираем имя клиента и сумму заказов
SELECT c.name, SUM(o.amount) AS total_amount
FROM customers c
JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'paid' -- только оплаченные
  AND o.created_at >= NOW() - INTERVAL '1 month' -- за последний месяц
GROUP BY c.name
ORDER BY total_amount DESC; -- по убыванию суммы

Почему это работает: Промт четко описывает таблицы, условия и сортировку. LLM не нужно додумывать — он просто переводит требования в SQL. Добавив комментарии, вы получаете само-документируемый код, который легко поддерживать.

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

Задача: найти и устранить узкие места в существующем запросе.

Промт:

Вот мой SQL-запрос. Он работает медленно (5 секунд на 1 млн строк). Проанализируй его и предложи оптимизации: индексы, переписывание, изменение структуры. Покажи, как изменится план выполнения (EXPLAIN ANALYZE).

SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE city = 'Moscow') AND amount > 1000;

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

1. Добавьте индексы: CREATE INDEX idx_orders_customer_amount ON orders(customer_id, amount); и CREATE INDEX idx_customers_city ON customers(city);
2. Перепишите с JOIN: SELECT o.* FROM orders o JOIN customers c ON c.id = o.customer_id WHERE c.city = 'Moscow' AND o.amount > 1000;
3. EXPLAIN ANALYZE покажет: до оптимизации Seq Scan по orders (5.2 сек), после — Index Scan (0.04 сек).

Почему это работает: LLM знает типичные ошибки — IN с подзапросом вместо JOIN, отсутствие индексов. Он не только предлагает исправления, но и объясняет, почему они ускоряют запрос.

3. Проектирование схемы PostgreSQL

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

Промт:

Спроектируй схему базы данных для интернет-магазина: товары, категории, заказы, пользователи, отзывы. Используй PostgreSQL. Опиши таблицы с типами данных, первичными и внешними ключами, ограничениями (CHECK, UNIQUE). Добавь индексы для частых запросов. Приведи примеры запросов для вывода товаров по категории и истории заказов пользователя.

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

CREATE TABLE categories (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    category_id INT REFERENCES categories(id) ON DELETE SET NULL,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10,2) CHECK (price >= 0),
    stock INT CHECK (stock >= 0)
);

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

-- ... остальные таблицы
CREATE INDEX idx_products_category ON products(category_id);
CREATE INDEX idx_orders_user ON orders(user_id);

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

4. Анализ JSONB в PostgreSQL

Задача: работать с полуструктурированными данными в JSONB.

Промт:

У меня есть таблица events с колонкой payload JSONB. Напиши запрос, который извлекает все события, где payload->'type' = 'click', и группирует их по дате, считая количество. Также покажи, как создать GIN-индекс для ускорения такого поиска.

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

SELECT DATE(created_at) AS day, COUNT(*)
FROM events
WHERE payload->>'type' = 'click'
GROUP BY day;

CREATE INDEX idx_events_payload_gin ON events USING GIN (payload);

Почему это работает: JSONB — мощный инструмент, но без индексов запросы к нему медленные. LLM знает про GIN-индексы и предлагает их автоматически.

5. MongoDB: агрегация для аналитики

Задача: написать сложный pipeline агрегации.

Промт:

У меня есть коллекция orders в MongoDB с документами вида: {_id, customer_id, items: [{product_id, price, qty}], created_at}. Напиши агрегационный pipeline для расчета выручки по каждому продукту за последний месяц, отсортированный по убыванию выручки. Включи стадию $match, $unwind, $group, $sort.

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

db.orders.aggregate([
  { $match: { created_at: { $gte: new Date(new Date().setMonth(new Date().getMonth() - 1)) } } },
  { $unwind: "$items" },
  { $group: { _id: "$items.product_id", total_revenue: { $sum: { $multiply: ["$items.price", "$items.qty"] } } } },
  { $sort: { total_revenue: -1 } }
])

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

6. Миграции данных между СУБД

Задача: перенести данные из PostgreSQL в MongoDB.

Промт:

У меня есть таблица users в PostgreSQL (id, name, email, created_at). Мне нужно перенести её в MongoDB, переименовав поле id в user_id и преобразовав created_at в ISO-дату. Напиши скрипт на Python с использованием psycopg2 и pymongo для миграции, включая обработку ошибок и логирование.

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

import psycopg2
from pymongo import MongoClient
from datetime import datetime

conn = psycopg2.connect("dbname=...")
cur = conn.cursor()
cur.execute("SELECT id, name, email, created_at FROM users")

mongo = MongoClient("mongodb://localhost:27017")
db = mongo["mydb"]
users = db["users"]

for row in cur:
    doc = {
        "user_id": row[0],
        "name": row[1],
        "email": row[2],
        "created_at": row[3].isoformat()
    }
    users.insert_one(doc)
    print(f"Migrated {row[0]}")

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

7. Объяснение и документирование схемы

Задача: быстро понять чужую базу данных.

Промт:

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

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

Структура:
- Таблица users — хранит пользователей, ключ id.
- Таблица orders — заказы, связана с users через customer_id.
- ...

Потенциальные проблемы: отсутствует индекс на orders.customer_id, что замедлит JOIN.

Улучшения: добавить индекс, рассмотреть партиционирование для больших таблиц.

Почему это работает: LLM выступает в роли аналитика, который быстро «читает» схему и выделяет важное. Это экономит часы на разборе чужого кода.

8. Оптимизация индексов в PostgreSQL

Задача: решить, какие индексы создать для набора запросов.

Промт:

У меня есть таблица transactions (id, user_id, amount, created_at, status). Частые запросы: выборка по user_id, фильтр по status, сортировка по created_at. Какие индексы ты посоветуешь? Учти, что запросов много, и лишние индексы замедляют запись.

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

• CREATE INDEX idx_transactions_user_created ON transactions(user_id, created_at); — покрывает выборку по пользователю с сортировкой.
• CREATE INDEX idx_transactions_status ON transactions(status); — для фильтрации по статусу.
• Избегайте отдельных индексов на created_at, если он уже в составном.

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

9. Написание хранимых процедур и триггеров

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

Промт:

Напиши триггер в PostgreSQL, который при вставке нового заказа в таблицу orders автоматически обновляет поле total_spent в таблице customers (сумма всех заказов). Учти, что заказ может быть изменен или удален.

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

CREATE OR REPLACE FUNCTION update_total_spent() RETURNS TRIGGER AS $$
BEGIN
    IF TG_OP = 'INSERT' THEN
        UPDATE customers SET total_spent = total_spent + NEW.amount WHERE id = NEW.customer_id;
    ELSIF TG_OP = 'UPDATE' THEN
        UPDATE customers SET total_spent = total_spent - OLD.amount + NEW.amount WHERE id = NEW.customer_id;
    ELSIF TG_OP = 'DELETE' THEN
        UPDATE customers SET total_spent = total_spent - OLD.amount WHERE id = OLD.customer_id;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_orders_change
AFTER INSERT OR UPDATE OR DELETE ON orders
FOR EACH ROW EXECUTE FUNCTION update_total_spent();

Почему это работает: LLM знает синтаксис PL/pgSQL и особенности триггеров, избавляя вас от тонкостей написания.

10. Диагностика и объяснение плана выполнения

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

Промт:

Вот вывод EXPLAIN ANALYZE для моего запроса. Объясни, что означает каждая часть, найди узкие места и предложи конкретные исправления.

Seq Scan on orders (cost=0.00..1234.56 rows=10000 width=100) (actual time=0.01..12.34 rows=10000 loops=1)
  Filter: (amount > 1000)

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

• Seq Scan — полное сканирование таблицы, значит нет подходящего индекса.
• Предлагаю создать индекс на amount: CREATE INDEX idx_orders_amount ON orders(amount);

Почему это работает: LLM обучался на множестве планов выполнения и может интерпретировать их не хуже опытного DBA.

11. Генерация тестовых данных

Задача: быстро заполнить базу репрезентативными данными.

Промт:

Сгенерируй SQL-скрипт для PostgreSQL, который вставляет 1000 тестовых пользователей в таблицу users (id, name, email, created_at). Используй генерацию случайных данных: имена из списка, email в формате имя.фамилия@example.com, created_at за последний год.

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

INSERT INTO users (name, email, created_at)
SELECT
  'User' || i,
'user'

|| i || '@example.com',
  NOW() - (random() * 365 || ' days')::interval
FROM generate_series(1, 1000) AS i;

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

12. Обучение и проверка знаний

Задача: быстро освоить новую СУБД или освежить знания.

Промт:

Я хочу изучить MongoDB. Составь план обучения на неделю: по дням, с практическими заданиями и примерами кода. Включи основы CRUD, агрегации, индексы и шардирование.

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

День 1: CRUD — вставка, чтение, обновление, удаление.

db.users.insertOne({name: "Alice"})
db.users.find({name: "Alice"})

День 2: Агрегации — $match, $group, $sort.
...

Почему это работает: LLM структурирует информацию, адаптируя её под ваш уровень, и предоставляет практические упражнения.

Как извлечь максимум из этих промтов

• Уточняйте контекст: чем больше деталей вы дадите (версии СУБД, объем данных, требования к производительности), тем точнее ответ.
• Используйте итеративный подход: не бойтесь задавать уточняющие вопросы в ответ на сгенерированный код.
• Проверяйте результаты: LLM может ошибаться, особенно в редких случаях. Всегда тестируйте код на реальных данных.
• Комбинируйте промты: например, сначала сгенерируйте схему, затем оптимизируйте запросы к ней.

Итоги

LLM не заменят опытного DBA, но они отлично справляются с рутиной: генерация запросов, оптимизация, проектирование схем. Эти 10 промтов — мой рабочий набор, который я использую почти каждый день. Они экономят часы и позволяют сосредоточиться на архитектуре, а не на синтаксисе. Попробуйте применить их в своих проектах — и вы увидите разницу.

Если у вас есть свои любимые промты для работы с базами данных — делитесь в комментариях!