Библиотека баз данных
Самая большая библиотека бесплатных книг по SQL По всем вопросам- @haarrp @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI РКН: № 5037640984
Больше📈 Аналитический обзор Telegram-канала Библиотека баз данных
Канал Библиотека баз данных (@sql_lib) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 10 343 подписчиков, занимая 11 961 место в категории Технологии и приложения и 63 498 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 10 343 подписчиков.
Согласно последним данным от 05 июня, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -68, а за последние 24 часа — -3, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 7.07%. В первые 24 часа после публикации контент обычно набирает N/A% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 732 просмотров. В течение первых суток публикация набирает 0 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 2.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как sql, субд, индекс, user_id, архитектура.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Самая большая библиотека бесплатных книг по SQL
По всем вопросам- @haarrp
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
РКН: № 5037640984”
Благодаря высокой частоте обновлений (последние данные получены 07 июня, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
inactive → banned → active?
У нас есть таблица логов смены статусов пользователей:
CREATE TABLE user_status_log (
user_id INT,
status TEXT, -- 'active', 'inactive', 'banned'
changed_at TIMESTAMP
);
Каждый раз, когда пользователь меняет статус, добавляется запись.
🔍 Найди пользователей, которые хотя бы один раз:
• стали inactive
• потом были banned
• и либо так и остались забанены, либо позже перешли в active
Важно:
• Статусы могут меняться много раз
• Нас интересует первая последовательность inactive → banned (→ optional `active`)
• Если пользователь не вернулся в `active`, всё равно считаем, что условие выполнено
---
🧠 Решение с оконными функциями:
WITH ranked_status AS (
SELECT
user_id,
status,
changed_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY changed_at) AS rn
FROM user_status_log
),
status_with_next AS (
SELECT
user_id,
status,
changed_at,
LEAD(status) OVER (PARTITION BY user_id ORDER BY changed_at) AS next_status,
LEAD(changed_at) OVER (PARTITION BY user_id ORDER BY changed_at) AS next_changed_at
FROM ranked_status
),
transitions AS (
SELECT
user_id,
changed_at AS from_time,
next_changed_at AS to_time,
status AS from_status,
next_status AS to_status
FROM status_with_next
WHERE next_status IS NOT NULL
),
flagged_users AS (
SELECT DISTINCT user_id
FROM (
SELECT
user_id,
MAX(CASE WHEN from_status = 'inactive' AND to_status = 'banned' THEN 1 ELSE 0 END) AS went_inactive_then_banned,
MIN(CASE WHEN from_status = 'banned' AND to_status = 'active' THEN 1 ELSE 0 END) AS banned_then_active
FROM transitions
GROUP BY user_id
) t
WHERE went_inactive_then_banned = 1
)
SELECT *
FROM flagged_users;
🧩 Почему это интересно?
• Используются оконные функции LEAD(), ROW_NUMBER()
• Нужно отслеживать последовательные пары статусов
• Объединяем логику в несколько CTE-слоёв
• Придётся думать не только о текущем статусе, но и о контексте (что было до и что после)
Подобные задачи — хороший способ прокачать мышление о временных событиях в SQL.pgvector. Это расширение позволяет сохранять и сравнивать векторы прямо внутри PostgreSQL.
📦 Установка PGVector (Linux)
git clone --branch v0.8.0 https://github.com/pgvector/pgvector.git
cd pgvector
make
sudo make install
Или просто:
• macOS: brew install pgvector
• Docker: pgvector/pgvector:pg17
• PostgreSQL 13+ (через APT/YUM)
🔌 Подключение расширения в базе
CREATE EXTENSION vector;
После этого ты можешь использовать новый тип данных vector.
🧱 Пример использования
Создаём таблицу:
CREATE TABLE items (
id bigserial PRIMARY KEY,
embedding vector(3)
);
Добавляем данные:
INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]');
Поиск ближайшего вектора:
SELECT * FROM items
ORDER BY embedding <-> '[3,1,2]'
LIMIT 5;
🧠 Операторы сравнения
PGVector поддерживает несколько видов расстояний между векторами:
- <-> — L2 (евклидово расстояние)
- <#> — скалярное произведение
- <=> — косинусное расстояние
- <+> — Manhattan (L1)
- <~> — Хэммингово расстояние (для битовых векторов)
- <%> — Жаккар (для битовых векторов)
Также можно усреднять вектора:
SELECT AVG(embedding) FROM items;
🚀 Индексация для быстрого поиска
HNSW (лучшее качество):
CREATE INDEX ON items USING hnsw (embedding vector_l2_ops);
Параметры можно настраивать:
SET hnsw.ef_search = 40;
#### IVFFlat (быстрее создаётся, но чуть менее точный):
CREATE INDEX ON items USING ivfflat (embedding vector_l2_ops) WITH (lists = 100);
SET ivfflat.probes = 10;
🔍 Проверка версии и обновление
SELECT extversion FROM pg_extension WHERE extname='vector';
ALTER EXTENSION vector UPDATE;
📌 Особенности
- Работает с PostgreSQL 13+
- Поддержка до 2000 измерений
- Расширяемый синтаксис
- Можно использовать DISTINCT, JOIN, GROUP BY, ORDER BY и агрегации
- Подходит для RAG-пайплайнов, NLP и встраивания LLM-поиска в обычные SQL-приложения
🔗 Подробнее
💡 Храни embedding'и прямо в PostgreSQL — и делай семантический поиск без внешних векторных БД.
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) Как обойти случай, если один и тот же друг записан несколько раз?
✅ Разбор подвоха
💣 Проблема: один пользователь может быть записан как друг несколько раз, особенно если приложение допускает дубли (или "перезапросы дружбы").
Пример:
INSERT INTO friends VALUES (1, 2), (1, 2), (1, 3);
В этом случае:
SELECT COUNT(friend_id) FROM friends WHERE user_id = 1;
-- → вернёт 3
Но реальных друзей у пользователя 1 — только 2: 2 и 3.
✅ Решение:
Используй COUNT(DISTINCT friend_id):
SELECT user_id, COUNT(DISTINCT friend_id) AS unique_friends
FROM friends
GROUP BY user_id
ORDER BY unique_friends DESC
LIMIT 1;
🎯 Дополнительно можно убрать самого пользователя из списка друзей (на случай ошибок):
WHERE user_id != friend_id
⚠️ Подвох
• COUNT() без DISTINCT ловит даже опытных — особенно если в БД возможны дубли
• LIMIT 1 не гарантирует "уникального победителя", если у нескольких одинаковый счёт
• Иногда friendship бывает и симметричной, тогда нужна защита от двойного счётаSELECT, JOIN, GROUP BY, транзакциями и многим другим
• Практическая информация для повседневной работы с реляционными базами данных
▪ Кому подойдёт?
• Новичкам — для быстрого старта
• Опытным разработчикам — как удобный справочник под рукой
• Всем, кто хочет систематизировать знания и избежать типичных ошибок
🔍 Важно знать
Эта книга — неофициальное, бесплатное учебное пособие, созданное на основе открытой документации Stack Overflow. Контент лицензирован по Creative Commons BY-SA. Использование информации осуществляется на свой страх и риск — авторы не гарантируют её абсолютную точность.
📥 *Идеальный материал для тех, кто предпочитает учиться на практических примерах и хочет всегда иметь под рукой концентрированное знание SQL.*
📎 Ссылка на скачивание
Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
