Дубликаты в данных — частая проблема, которая может привести к некорректным аналитическим выводам, ошибкам в расчетах или ухудшению пользовательского опыта.
Например, дублированные email-адреса в CRM увеличивают расходы на email-рассылки, а повторяющиеся записи о заказах — риск двойного начисления бонусов.
Из прикреплённых к посту карточек вы узнаете, как найти их с помощью SQL.
#sql #data #tips #database #productivity
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥2
Вы когда-нибудь сталкивались с ситуацией, когда вам срочно нужны данные, а аналитик занят? Или вы получаете отчет, который не отвечает на ваш вопрос, и приходится ждать перезапроса?
У меня такое постоянно)) Поэтому в последнее время часто пишу SQL-запросы в обнимку с LLM-моделью (мог бы и сам, но с моделью быстрее😉).
LLM не заменяет аналитика, но помогает сгенерировать правильный запрос, если передать в модель минимально достаточный контекст.
📦 Что собрать перед запросом к LLM
Для качественного ответа LLM нужно передать 4 ключевых блока (👀см.скрин)
✨ Как передать данные LLM: шаблон промпта
Если у вас есть набор таблиц, с которым вы часто работаете, вот структурированный текст, который вы можете скопировать, заполнить и использовать для генерации запросов с помощью LLM:
У меня есть следующие таблицы в базе данных Postgres:
Таблица: users
Описание: Информация о пользователях платформы
Колонки:
- user_id (INT, PK): Уникальный ID пользователя
- email (VARCHAR): Email пользователя
- signup_date (DATE): Дата регистрации
Таблица: orders
Описание: Заказы пользователей
Колонки:
- order_id (INT, PK): Уникальный ID заказа
- user_id (INT, FK → users.user_id): Кто сделал заказ
- order_date (TIMESTAMP): Дата заказа
- amount (DECIMAL): Сумма заказа
- status (VARCHAR): Статус ("completed", "cancelled", "pending")
Связи:
- orders.user_id ссылается на users.user_id
Пример данных (orders):
| order_id | user_id | order_date | amount | status |
|----------|---------|---------------------|--------|----------|
| 101 | 5 | 2025-10-01 14:30:00 | 99.99 | completed|
Бизнес-логика:
- Активный пользователь — заходил в систему за последние 7 дней.
- Отмененные заказы (status = 'cancelled') не учитываются в выручке.
Запрос пользователя:
"Составь SQL запрос для расчёта общей выручки по месяцам за 2025 год."
💡 Советы для повышения качества генерации
— Указывайте СУБД
Синтаксис отличается: PostgreSQL, Vertica, Trino, Clickhouse — упомяните, какая система используется.
— Четко формулируйте цель
Лучше: «Покажи выручку по месяцам за 2025 год, учитывая только статус completed»
Хуже: «Нужна статистика по продажам»
— Ограничивайте scope
Не передавайте всю БД — только релевантные таблицы. Это снизит шум и повысит точность.
— Вместо ручного составления описания таблиц можно автоматически получить метаданные через системные таблицы вашей БД. Например для Postgres:
SELECT
tbl.table_name,
col.column_name,
col.data_type,
pg_catalog.col_description(c.oid, col.ordinal_position::int) AS column_comment
FROM information_schema.tables tbl
JOIN information_schema.columns col ON col.table_name = tbl.table_name
JOIN pg_catalog.pg_class c ON c.relname = tbl.table_name
WHERE tbl.table_schema = 'public'
AND tbl.table_type = 'BASE TABLE'
ORDER BY tbl.table_name, col.ordinal_position;
Скопируйте результат в формате таблицы или JSON
Вставьте в промпт LLM вместо ручного описания структуры
А вы уже пробовали генерировать SQL через LLM? Делитесь в комментариях — какие фишки помогают вам!
#tips #llm #sql #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤5
Если ваш сервис использует в качестве БД PostgreSQL и вы часто пишете SQL-запросы для аналитики — вам знакома боль: «а какая там колонка?», «как называется связующая таблица?», «какие индексы есть?».
Обычно лезут в pg_catalog или DBeaver, но есть способ проще и удобнее — особенно если вы используете LLM для генерации запросов.
Забудьте про системные таблицы — встречайте
pg_dump 🔥 — утилиту командной строки из поставки PostgreSQL, которая создаёт резервные копии БД. Но её можно использовать и для экспорта схемы данных в читаемом виде. И это идеальный способ получить полный контекст для LLM.(👀 см. карточки ↑)
⚠️ Важные нюансы
— Фильтруйте чувствительные данные перед отправкой в LLM: удалите комментарии с секретами, триггеры с логикой бизнес-правил.
— Обрезайте большой дамп — если схема огромная, оставьте только релевантные таблицы для задачи.
— Используйте
.pgpass — чтобы не вводить пароль каждый раз при запуске pg_dump.Промпт для генерации описания таблиц на основе схемы из
pg_dump:Проанализируй схему PostgreSQL, полученную через утилиту pg_dump (включая CREATE TABLE-запросы, комментарии к таблицам и колонкам, а также определения внешних ключей), и сформируй структурированное описание каждой таблицы в следующем формате:
# Описание таблиц BI-системы
## Хранилище данных: PostgreSQL
### Таблица: [название таблицы]
**Описание:** [Текст из COMMENT ON TABLE. Если комментарий отсутствует, сформулируй краткое описание на основе названия таблицы и контекста.]
**Колонки:**
- **[имя колонки]** ([тип данных]): [Текст из COMMENT ON COLUMN. Если комментарий отсутствует, опиши назначение на основе названия колонки и типа данных. Для внешних ключей добавь: "Ссылка на [таблица].[колонка] ([пояснение связи, например: 'определяет контекст видимости', 'используется для проверки условий']".]
**Бизнес-логика:**
- [Перечисли ключевые аспекты логики на основе:
1. Связей через внешние ключи (например: "Связь с [таблица] через [колонка] определяет [логика]"),
2. Флагов/статусов (например: "Использование флага [колонка] позволяет [действие]"),
3. Контекста из комментариев (например: "Алерты срабатывают при [условие] на основе данных из [таблица]").
Каждый пункт должен начинаться с тире и содержать пояснение, как колонка или связь влияет на бизнес-процессы.]
---
Требования к оформлению:
1. Используй строгую структуру с markdown-заголовками (###, **, -).
2. Для внешних ключей в разделе "Колонки" всегда указывай связанную таблицу и логику связи (например: "Ссылка на queries.id, по результатам которого проверяются условия алерта").
3. В "Бизнес-логике" фокусируйся на взаимодействии таблиц, условиях срабатывания, правах доступа и других бизнес-аспектах (не технических деталях).
4. Если в схеме отсутствуют комментарии, сделай обоснованные выводы на основе названий колонок и типов данных (например, `is_active` → "Флаг активности записи").
5. Не добавляй информацию, которой нет в схеме (только то, что можно вывести из pg_dump и логических связей).
Пример корректного описания для таблицы alerts (как в приложенном файле) должен быть воспроизведен для каждой таблицы в схеме.
🤌 Итого
pg_dump — это не только для бэкапов. Это мощный инструмент для ускорения работы с данными, особенно в связке с LLM. Вы экономите время на рутине и фокусируетесь на том, что действительно важно — анализе и принятии решений.См.также
— Как писать SQL-запросы с помощью LLM: гайд для менеджеров без аналитиков
— Pg_dump документация
#tips #llm #sql #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤5👍3