SQL и Анализ данных

Отменяем все мемы про дроп базы

🐳 Как запустить DeepSeek у себя на ПК через Python

Главная ошибка новичков - сразу ставить огромные модели.
Начни с компактной версии, проверь, что всё запускается, и только потом увеличивай размер.

Алгоритм простой:
1) ставим зависимости
2) качаем лёгкую модель DeepSeek
3) проверяем, что она отвечает
4) при необходимости включаем GPU или берём квантизованную версию

Так ты избежишь вылетов, перегрузки памяти и быстрее получишь рабочий результат.

установить зависимости
pip install transformers accelerate torch sentencepiece

# пример запуска DeepSeek из Python
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = "deepseek-ai/deepseek-coder-6.7b-base"

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    device_map="auto"   # если есть GPU — модель сама её использует
)

prompt = "Напиши на Python функцию, которая проверяет, простое ли число."

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

outputs = model.generate(
    **inputs,
    max_new_tokens=160,
    temperature=0.4
)

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

https://uproger.com/kak-zapustit-deepseek-u-sebya-na-pk/

⚡️ ИИ для SQL: пусть он объяснит «почему запрос тормозит»

Профессиональный лайфхак:
не проси ИИ «оптимизировать запрос» вслепую.
Вместо этого — давай ему EXPLAIN / EXPLAIN ANALYZE и структуру таблиц.

ИИ отлично умеет:
- разбирать план выполнения
- находить узкие места (Seq Scan, лишние JOIN, сортировки)
- предлагать индексы и переписывание запроса по факту, а не наугад

Алгоритм простой:
1️⃣ запускаешь EXPLAIN ANALYZE
2️⃣ прикладываешь схему таблиц
3️⃣ спрашиваешь: *где bottleneck и что бы ты поменял?*

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

пример «правильного» запроса к ИИ с реальными данными

-- запрос
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
AND c.country = 'US'
ORDER BY o.created_at DESC
LIMIT 100;

-- план выполнения
EXPLAIN ANALYZE
SELECT ...
-- (сюда вставь полный план: Seq Scan / Index Scan / сортировки и т.п.)

-- схема таблиц (важно!)
\d orders
\d customers

-- вопрос ИИ:
"Разбери план выполнения. 
Где узкие места? 
Нужны ли индексы и какие именно? 
Можно ли переписать запрос быстрее, не меняя логику?"

https://www.youtube.com/shorts/LcLMwpVMKNQ

🖥 Продвинутый SQL-совет по оптимизации: делай запросы "питающимися индексом" (index-only scan) с правильным составным индексом.

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

Допустим, у тебя часто есть такой запрос:

SELECT
    id,
    created_at,
    total_amount
FROM orders
WHERE user_id = 123
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

Типичная ошибка - делать что-то вроде:

CREATE INDEX idx_orders_user ON orders (user_id);
CREATE INDEX idx_orders_status ON orders (status);
CREATE INDEX idx_orders_created ON orders (created_at);

Планировщику всё равно приходится лазить в таблицу и склеивать условия. Гораздо эффективнее один правильный составной индекс:

CREATE INDEX idx_orders_user_status_created_at
ON orders (user_id, status, created_at DESC)
INCLUDE (total_amount);

Почему это полезно:

user_id, status - фильтруют строки

created_at DESC - сразу даёт нужный порядок для ORDER BY ... DESC

INCLUDE (total_amount) - позволяет взять сумму прямо из индекса

В результате PostgreSQL (и другие СУБД с подобной механикой) могут сделать index-only scan: прочитать подходящие строки в нужном порядке из одного индекса и почти не трогать основную таблицу.

🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты?

Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом.

Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям.

Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт.

🎁 48 часов действует новогодняя скидка в 40% процентов

👉 Начать учиться на Stepik

🖥 Docker большой исчерпывающий курс. Глава 1. Архитектура, понятия и первый запуск

Курс по Docker, написанный программистами для программистов. Мы выкинули историю контейнеризации и скучную теорию.

Вместо этого жесткая практика: ментальные модели через ООП, анатомия Linux-процессов, написание Dockerfile, docker-compose и подготовка к продакшену.

Экономь время: учись только тому, что реально используется в индустрии

https://uproger.com/docker-bolshoj-ischerpyvayushhij-kurs-glava-1-arhitektura-ponyatiya-i-pervyj-zapusk/

🖥 SQL-квест: фэнтезийное приключение для аналитиков данных

Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах.

🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮

В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты.

Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест.

🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/

🖥 SQL совет: как избежать хитрой ошибки с LEFT JOIN

Одна из самых коварных SQL-ошибок возникает при использовании LEFT JOIN вместе с условиями в WHERE.

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

Почему так происходит
Если в WHERE есть условие на колонку из присоединенной таблицы,
строки с NULL автоматически отфильтровываются.

В итоге:
- LEFT JOIN есть
- но результат как у INNER JOIN
- данные «пропадают», и баг сложно заметить

Правильное правило
Все условия для таблицы из LEFT JOIN:
- должны быть в ON
- а не в WHERE

Иначе ты теряешь строки, где JOIN не сработал.

Когда это особенно опасно
- отчеты и аналитика
- подсчет метрик
- поиск «отсутствующих» данных
- антиджойны

Эта ошибка не ломает запрос.
Она ломает доверие к данным.

🖥 SQL-совет по оптимизации - используй DISTINCT ON вместе с правильным индексом (PostgreSQL)

DISTINCT ON часто недооценивают, но в PostgreSQL это один из самых быстрых способов выбрать «последнюю запись на группу» без подзапросов и оконных функций.

Проблема
Нужно получить, например, последнюю запись по каждому user_id, отсортированную по created_at.

Типичное (медленное) решение
- оконная функция ROW_NUMBER()
- подзапрос с GROUP BY + JOIN

Редкое и очень быстрое решение
DISTINCT ON + индекс, совпадающий с ORDER BY.

Пример
Получаем последнюю сессию каждого пользователя.

SELECT DISTINCT ON (user_id)
       user_id,
       session_id,
       created_at
FROM user_sessions
ORDER BY user_id, created_at DESC;

Почему это быстро
PostgreSQL берет первую строку на каждую группу user_id согласно ORDER BY и сразу останавливается - без сортировки всего результата и без оконных функций.

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

CREATE INDEX idx_user_sessions_distinct
ON user_sessions (user_id, created_at DESC);

Что дает такой индекс
- Index Scan вместо Seq Scan
- Нет дополнительной сортировки
- Очень быстрый выбор «последней записи на группу» даже на миллионах строк

Где особенно полезно
- логины пользователей
- события
- статусы
- версии сущностей
- time-series данные

DISTINCT ON - это PostgreSQL-специфичная оптимизация, но если ты работаешь с Postgres, это один из самых мощных и редких трюков.

🛠️ Легкий TUI для работы с SQL базами данных

sqlit - это удобный инструмент для быстрого выполнения запросов к различным SQL базам данных, включая PostgreSQL, MySQL, SQLite и другие. Он предлагает интуитивно понятный интерфейс, позволяя легко управлять соединениями и историей запросов без необходимости в сложных настройках.

🚀Основные моменты:
- Поддержка множества баз данных без дополнительных адаптеров
- Удобный интерфейс для управления соединениями
- Встроенная история запросов с возможностью поиска
- Поддержка SSH туннелей для безопасного подключения
- Редактирование в стиле Vim для терминальных пользователей

📌 GitHub: https://github.com/Maxteabag/sqlit

#python

💡Полезный SQL-совет

Если тебе нужно быстро проверить существование строк - никогда не используй `COUNT(*)`.

❌ Плохо:

SELECT COUNT(*) FROM orders WHERE user_id = 42;

✅ Правильно:

SELECT 1 FROM orders WHERE user_id = 42 LIMIT 1;

Почему:
- `COUNT(*)` считает все строки  
- `EXISTS` / `LIMIT 1` останавливаются на первом совпадении  
- На больших таблицах разница — кратная

Лучший вариант:
SELECT EXISTS (
  SELECT 1 FROM orders WHERE user_id = 42
);

Меньше I/O, меньше CPU, быстрее запрос.

🖥 usql - универсальный SQL-клиент для работы с любыми базами данных

usql — это интерактивный SQL-клиент, который объединяет работу с разными СУБД в одном инструменте. По ощущениям он похож на psql, но поддерживает сразу множество баз данных и не привязывает тебя к одному движку.

Главная идея usql — один клиент для всех SQL-баз.

Что умеет usql:

- Подключение к PostgreSQL, MySQL, SQLite, MSSQL, Oracle, ClickHouse, CockroachDB, MariaDB и другим СУБД
- Единый интерфейс и одинаковые команды для разных движков
- Интерактивный режим с историей команд и автодополнением
- Удобный табличный вывод результатов
- Запуск SQL-скриптов из файлов
- Гибкая настройка цветов, форматов и pager’а

Почему это удобно:

- Не нужно держать десяток разных клиентов
- Не нужно переключать мышление между psql, mysql и sqlcmd
- Один привычный REPL для аналитики и администрирования
- Отлично подходит для работы сразу с несколькими базами

Кому особенно полезен usql:
- backend-разработчикам
- аналитикам данных
- DevOps-инженерам
- всем, кто регулярно работает с разными СУБД

Если ты живёшь в терминале и часто общаешься с SQL-базами, usql быстро становится инструментом по умолчанию.

github.com/xo/usql/

🖥 Гайд по продвинутому профессиональному использованию SQL

В этом руководстве мы рассмотрим ключевые аспекты работы с SQL на практике. Начнём с сравнения популярных СУБД, затем перейдём к продвинутым приёмам аналитического SQL, оптимизации запросов, администрированию баз данных, и закончится всё интеграцией SQL с Python (SQLAlchemy, pandas и т.д.).

Для каждого раздела приведены примеры на реальных сценариях (интернет-магазин, CRM, аналитика продаж), код и полезные советы.

👉 Читать гайд

Когда батя айтишник