🧠 SQL-задача с подвохом: “Найди самого активного… по количеству разных друзей”

📘 Условие

У тебя есть таблица дружбы:

friends(user_id, friend_id)

Здесь каждая строка означает, что user_id дружит с friend_id.
Записи всегда односторонние: если есть (1, 2), это не значит, что будет (2, 1).

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

❓ Пример попытки:

SELECT user_id, COUNT(friend_id) AS total_friends
FROM friends
GROUP BY user_id
ORDER BY total_friends DESC
LIMIT 1;

🔍 Вопрос:

1) В чём здесь может быть логическая ошибка?
2) Какую строку подсчитает COUNT(friend_id)?
3) Когда нужно использовать COUNT(DISTINCT friend_id)?
4) Как обойти случай, если один и тот же друг записан несколько раз?

✅ Разбор подвоха

💣 Проблема: один пользователь может быть записан как друг **несколько раз**, особенно если приложение допускает дубли (или "перезапросы дружбы").

Пример:

```sql
INSERT INTO friends VALUES (1, 2), (1, 2), (1, 3);
```

В этом случае:

```sql
SELECT COUNT(friend_id) FROM friends WHERE user_id = 1;
-- → вернёт 3
```

Но реальных друзей у пользователя `1` — только **2**: `2` и `3`.

✅ Решение:

Используй `COUNT(DISTINCT friend_id)`:

```sql
SELECT user_id, COUNT(DISTINCT friend_id) AS unique_friends
FROM friends
GROUP BY user_id
ORDER BY unique_friends DESC
LIMIT 1;
```

🎯 Дополнительно можно убрать самого пользователя из списка друзей (на случай ошибок):

```sql
WHERE user_id != friend_id
```

⚠️ Подвох

• `COUNT()` без `DISTINCT` ловит даже опытных — особенно если в БД возможны дубли
• `LIMIT 1` не гарантирует "уникального победителя", если у нескольких одинаковый счёт
• Иногда friendship бывает и симметричной, тогда нужна защита от двойного счёта

🔥 Polars: шпаргалка

Polars ≠ Pandas. Это колоночный движок, вдохновлённый Rust и SQL. Никаких SettingWithCopyWarning — всё иммутабельно и параллелится.

🚀 Быстрый старт

import polars as pl

df = pl.DataFrame({
    "id": [1, 2, 3],
    "name": ["Alice", "Bob", "Charlie"],
    "score": [95, 85, 100]
})

📊 Выборка и фильтрация

df.filter(pl.col("score") > 90)
df.select(pl.col("name").str.lengths())
df[df["id"] == 2]

• Комбинированные условия:

df.filter((pl.col("score") > 80) & (pl.col("name").str.contains("A")))

---

## ⚙️ Трансформации

• Вычисление новых колонок:

df.with_columns([
    (pl.col("score") / 100).alias("percent"),
    pl.col("name").str.to_uppercase().alias("name_upper")
])

• Удаление/переименование:

df.drop("id").rename({"name": "username"})

• apply() — только если нельзя обойтись иначе:

df.with_columns(
    pl.col("score").map_elements(lambda x: x * 2).alias("doubled")
)

🧠 Группировка и агрегаты

df.groupby("name").agg([
    pl.col("score").mean().alias("avg_score"),
    pl.count()
])

• Агрегация с кастомной функцией:

df.groupby("name").agg(
    (pl.col("score") ** 2).mean().sqrt().alias("rms")
)

---

## 🪄 Ленивая обработка (LazyFrame)

lf = df.lazy()
result = (
    lf
    .filter(pl.col("score") > 90)
    .with_columns(pl.col("score").log().alias("log_score"))
    .sort("log_score", descending=True)
    .collect()
)

✅ Всё оптимизируется *до выполнения* — pushdown, predicate folding, projection pruning.

🔥 Joins

df1.join(df2, on="id", how="inner")

Варианты: "inner", "left", "outer", "cross", "semi", "anti"

📂 Работа с файлами

pl.read_csv("data.csv")
df.write_parquet("out.parquet")
pl.read_json("file.json", json_lines=True)

Ленивая загрузка:

pl.read_parquet("big.parquet", use_pyarrow=True).lazy()

---

## 🧮 Аналитика и окна

df.with_columns([
    pl.col("score").rank("dense").over("group").alias("rank"),
    pl.col("score").mean().over("group").alias("group_avg")
])

🧱 Структуры, списки, explode

df = pl.DataFrame({
    "id": [1, 2],
    "tags": [["a", "b"], ["c"]]
})
df.explode("tags")

• Работа с вложенными списками:

df.select(pl.col("tags").list.lengths())

🧪 Полезные фичи

• Проверка типов:

df.schema
df.dtypes

• Проверка на null:

df.filter(pl.col("score").is_null())

• Заполнение:

df.fill_null("forward")

• Выбор n лучших:

df.sort("score", descending=True).head(5)

📦 Советы и best practices

• Используй lazy() для производительности.

• Избегай .apply() — если можешь, используй pl.col().map_elements() или векторные выражения.

• Сохраняй schema — удобно при пайплайнах данных.

• @pl.api.register_expr_namespace("yourns") — добавляй кастомные методы как namespace.


✅ Polars: минимализм, скорость, безопасность.

🛠️ Bob

Bob — это универсальный инструмент для работы с SQL в Go, который сочетает в себе:
• генератор кода
• ORM-подход
• гибкий конструктор SQL-запросов

📌 Что умеет Bob:

🔹 Генерация моделей и фабрик
Автоматически создаёт Go-код по схеме вашей базы данных. Ускоряет работу с моделями и минимизирует ручную писанину.

🔹 Поддержка PostgreSQL, MySQL, SQLite
Работает с самыми популярными базами данных — удобно для любых проектов.

🔹 Генерация типобезопасного кода из SQL
Как в sqlc, но с поддержкой дополнительных ORM-фич.

🔹 Гибкий конструктор запросов
Строит SQL-запросы на Go с читабельным синтаксисом — без ручной сборки строк.

🔹 Поддержка связей (associations)
Автоматически определяет связи между таблицами по внешним ключам. Включает has-one, has-many, has-many-through и др.

📚 Подробнее:
▪ GitHub: https://github.com/stephenafamo/bob
▪ Документация: https://bob.stephenafamo.com/docs/code-generation/intro

Если ты работаешь с Go и SQL — попробуй Bob. Это как sqlc, но с усиленной ORM-магией.

🗃️ Stoolap — лёгкая и быстрая SQL-база данных на чистом Go без зависимостей

Stoolap — это современный HTAP-движок (Hybrid Transactional/Analytical Processing), сочетающий OLTP и OLAP в одном ядре. Подходит как для транзакционных задач, так и для аналитики.

🚀 Возможности:
• Полностью написан на Go — никаких внешних зависимостей
• ACID-транзакции через MVCC
• Колонковое хранение с SIMD-ускорением
• Поддержка SQL: JOIN, агрегаты, оконные функции
• Встроенный тип JSON
• Поддержка database/sql и интеграция с GORM
• CLI-режим и in-memory база

📦 Установка:

go get github.com/stoolap/stoolap

🔥 Быстрый старт (CLI):

stoolap -db memory://

📎 Репозиторий: https://github.com/stoolap/stoolap
🌐 Сайт: https://stoolap.io


@golang_google

🚀 Представлен Apache Spark 4.0 — крупнейший релиз с момента запуска Spark 2.0

Databricks анонсировали Spark 4.0 с множеством фундаментальных улучшений производительности и архитектуры.

Новый релиз фокусируется на ускорении обработки, поддержке GenAI-нагрузок и расширенной масштабируемости.

🔥 Что нового:

• 💡 Project Tungsten++, Catalyst++ — переработка движка исполнения и оптимизации запросов
• 🧠 Поддержка генеративных AI-запросов — Spark теперь эффективнее работает с LLM-нагрузками
• ⚙️ Новый Execution Engine — более 2× ускорение в среднем, до 10× в некоторых кейсах
• 📦 Модульная архитектура — теперь ядро Spark отделено от MLlib, GraphX и др.
• 🌐 Поддержка нового Shuffle-движка и улучшенное распределение по кластерам
• 🧪 Обратная несовместимость — Spark 4.0 требует миграции, особенно для UDF и кастомных оптимизаций

📌 Подробности и тесты:
https://www.databricks.com/blog/introducing-apache-spark-40

@data_analysis_ml

⚡️ SQL-шпаргалка, которая выручит в интервью, проекте и проде

Полный мастер-гайд по SQL в одном PDF: практичные примеры, чёткие объяснения и никакой воды.

Что внутри:
• 💬 Создание баз, таблиц и изменение схем
• 💬 Запросы любого уровня сложности: JOIN, GROUP BY, HAVING, PARTITION
• 💬 Подзапросы, CTE, оконные функции: ROW_NUMBER, RANK, DENSE_RANK
• 💬 VIEW, временные таблицы и работа с дубликатами
• 💬 Даты, строки, преобразования и агрегации
• 💬 Очистка данных, разбиение по разделителям
• 💬 UNION, INTERSECT, EXCEPT — управление сложными выборками

Затрагиваются и продвинутые кейсы:
• Парсинг адресов
• Кастомная сортировка
• Использование ISNULL и COALESCE

🧠 Это не просто набор команд — это концентрат боевого SQL-опыта.

Подходит для:
➡️ Подготовки к SQL-интервью
➡️ BI и аналитики
➡️ Web-разработки с базами
➡️ Встраивания SQL в проекты на Python, Go, Java и других языках

🧩 SQL-задача с подвохом: "Сотрудники без продаж в 2024 году"

У тебя есть две таблицы:

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR
);

CREATE TABLE sales (
    id SERIAL PRIMARY KEY,
    employee_id INT,
    sale_amount NUMERIC,
    sale_date DATE
);

📌 Задание:
Найди всех сотрудников, у которых не было ни одной продажи в 2024 году.


💣 **Подвох:**
Многие делают LEFT JOIN sales ON ... WHERE sale.id IS NULL, но это покажет только тех, у кого вообще не было продаж.
А нужно — у кого не было продаж именно в 2024 году, даже если они были в 2023 или 2022.

💡 **Подсказки:**

• Отфильтруй sales по дате (`2024-01-01` до `2024-12-31`)
• Используй LEFT JOIN или NOT EXISTS
• Ищи NULL только после фильтра

---

✅ Решение с `LEFT JOIN`:

```sql
SELECT e.name
FROM employees e
LEFT JOIN (
SELECT * FROM sales
WHERE sale_date >= '2024-01-01' AND sale_date < '2025-01-01'
) s ON e.id = s.employee_id
WHERE s.id IS NULL;
```

---

🔄 **Альтернатива с `NOT EXISTS`:**

```sql
SELECT name
FROM employees e
WHERE NOT EXISTS (
SELECT 1
FROM sales s
WHERE s.employee_id = e.id
AND s.sale_date >= '2024-01-01'
AND s.sale_date < '2025-01-01'
);
```

---

🎯 Отличная задача, чтобы понять, **где правильно ставить фильтрацию по дате**, и чем `LEFT JOIN` отличается от `NOT EXISTS`.

🧠 SkyRL-SQL — лёгкий RL-подход для Text-to-SQL от NovaSky, который превзошёл GPT-4o и o4-mini, обучаясь всего на 653 примерах!

📌 Что это:
SkyRL-SQL — это эффективный RL-фреймворк для генерации SQL-запросов из текста.
Модель SkyRL-SQL-7B обучена с нуля с использованием обучения с подкреплением (reinforcement learning), без гигантских датасетов.

📊 Результаты на Spider-бенчмарках:

| Модель | Spider-Dev | Spider-Test | Realistic | DK | Syn | Среднее |
|--------------------|------------|-------------|-----------|------|------|---------|
| GPT-4o | 81.3 | 82.4 | 80.1 | 72.1 | 71.9 | 77.6 |
| o4-mini | 80.6 | 81.8 | 81.2 | 70.8 | 72.1 | 77.3 |
| **SkyRL-SQL-7B** | **83.9** | **85.2** | **81.1** | 72.0 | 73.7 | **79.2** |

🔍 Особенности:
• RL-обучение по шагам с интерактивной проверкой
• Поддержка уточнения SQL на основе ошибок
• Обучение всего на 653 примерах
• Превосходит более крупные модели на практике

GitHub: https://github.com/NovaSky-AI/SkyRL
Блог: https://novasky-ai.github.io/posts/skyrl-sql

🧪 Отличный пример того, как можно бить гигантов с умной архитектурой, а не только размерами.

📌 Github

🛠️ Что нового в SQLite — свежие обновления и улучшения

🔗 https://www.sqlite.org/changes.html

SQLite — одна из самых популярных встраиваемых баз данных в мире, и каждое обновление приносит не только исправления, но и серьёзные улучшения производительности и безопасности.

Вот ключевые изменения из последних версий:

🆕 SQLite 3.46.0 (май 2024)

- Добавлена поддержка contentless-delete для таблиц FTS5 — меньше места, выше скорость
- Новый флаг SQLITE_DBCONFIG_STMT_SCANSTATUS — можно отключать сбор статистики по выполнению запросов
- Оптимизации для LEFT JOIN + OR условий в WHERE — запросы выполняются заметно быстрее
- Улучшено поведение WITHOUT ROWID таблиц с составными ключами

🧪 Расширенные тесты:
- SQLite теперь использует дополнительный fuzzing для анализа стабильности ядра при высоких нагрузках и необычных SQL

🧹 Также исправлены:
- Ошибки в индексах при сложной комбинации JOIN + USING
- Утечка памяти при специфическом использовании PRAGMA function_list

💡 SQLite остаётся одной из самых лёгких, надёжных и удобных баз данных, которую можно использовать буквально везде: от браузеров и мобильных приложений до IoT и CLI-утилит.

📚 Полный список изменений — здесь:
https://www.sqlite.org/changes.html

@sqlhub

🔥 CTE + DELETE — это комбинация общего табличного выражения (Common Table Expression, CTE) и оператора DELETE, которая позволяет удобно удалять строки из таблицы, особенно в случаях, когда удаление зависит от сложного подзапроса или JOIN-ов.

🔍 Что такое CTE?
CTE (WITH выражение) — это временный набор данных, определённый перед основным SQL-запросом.

🧹 Зачем использовать CTE с DELETE?
Упрощает чтение и понимание кода при сложных условиях.

Позволяет использовать JOIN, ROW_NUMBER() и другие функции перед удалением.

Избавляет от подзапросов в WHERE, которые иногда трудно читать.

📌 Пример: Удалить дубликаты по email, оставив только один

WITH duplicates AS (
    SELECT id,
           ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
    FROM users
)
DELETE FROM users
WHERE id IN (
    SELECT id FROM duplicates WHERE rn > 1
);  

🧠 Здесь:

CTE duplicates присваивает каждой строке номер внутри группы одинаковых email.

Удаляем все строки, где rn > 1 — то есть дубликаты.

📌 Пример: Удаление с JOIN

WITH to_delete AS (
    SELECT u.id
    FROM users u
    JOIN orders o ON u.id = o.user_id
    WHERE o.status = 'cancelled'
)
DELETE FROM users
WHERE id IN (SELECT id FROM to_delete);

📌 Поддержка:
Работает в PostgreSQL, SQL Server, Oracle (с USING или WITH).

В MySQL с 8.0+ CTE поддерживаются, но DELETE с CTE может потребовать подзапрос.