Библиотека баз данных
Самая большая библиотека бесплатных книг по SQL По всем вопросам- @haarrp @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI РКН: № 5037640984
Mostrar más📈 Análisis del canal de Telegram Библиотека баз данных
El canal Библиотека баз данных (@sql_lib) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 345 suscriptores, ocupando la posición 11 961 en la categoría Tecnologías y Aplicaciones y el puesto 63 498 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 345 suscriptores.
Según los últimos datos del 05 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -68, y en las últimas 24 horas de -3, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 7.07%. Durante las primeras 24 horas tras publicar, el contenido suele obtener N/A% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 732 visualizaciones. En el primer día suele acumular 0 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 2.
- Intereses temáticos: El contenido se centra en temas clave como sql, субд, индекс, user_id, архитектура.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Самая большая библиотека бесплатных книг по SQL
По всем вопросам- @haarrp
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
РКН: № 5037640984”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 06 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
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.*
📎 Ссылка на скачивание
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
