Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Больше📈 Аналитический обзор Telegram-канала Data Science. SQL hub
Канал Data Science. SQL hub (@sqlhub) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 35 853 подписчиков, занимая 3 833 место в категории Технологии и приложения и 18 125 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 35 853 подписчиков.
Согласно последним данным от 12 июня, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило 8, а за последние 24 часа — -2, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 10.08%. В первые 24 часа после публикации контент обычно набирает 4.38% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 3 614 просмотров. В течение первых суток публикация набирает 1 571 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 15.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как sql, индекс, postgres, index, sqlite.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Благодаря высокой частоте обновлений (последние данные получены 13 июня, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
pandas.read_sql и вернуть подставные данные.
Пример функции:
def query_user_data(user_id):
query = f"SELECT id, name FROM users WHERE id = {user_id}"
return pd.read_sql(query, "postgresql://localhost/mydb")
Тест с моком:
from unittest.mock import patch
import pandas as pd
@patch("pandas.read_sql")
def test_database_query_mocked(mock_read_sql):
mock_read_sql.return_value = pd.DataFrame(
{"id": [123], "name": ["Alice"]}
)
result = query_user_data(user_id=123)
assert result["name"].iloc[0] == "Alice"
Теперь вместо запроса в реальную базу тест подставляет фейковые данные. Так можно проверить бизнес-логику функции быстро и надёжно.
@sqlhubuuidv7() — UUID с временной сортировкой
- Сохранение статистики планировщика при мажорных апгрейдах
- Поддержка OAuth 2.0, улучшения TLS и безопасности
- Новый протокол взаимодействия клиентов и утилит — v3.2
🟠 Релиз: https://www.postgresql.org/about/news/postgresql-18-released-3142/
conn.execute("BEGIN TRANSACTION")
try:
conn.execute("UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice'")
conn.execute("UPDATE accounts SET balance = balance + 200 WHERE name = 'Bob'")
conn.execute("COMMIT")
except:
conn.execute("ROLLBACK")
🔹 Atomicity — либо всё, либо ничего
🔹 Consistency — база не ломается
🔹 Isolation — параллельные операции не мешают
🔹 Durability — данные не теряются
🛡 ACID гарантирует надёжность даже при сбоях.SELECT до оптимизации запросов и реальных кейсов.
🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course
Сохраняй, проходи и прокачивай SQL 💡
@sqlhubQUALIFY (в Snowflake, BigQuery, DuckDB, Trino):
SELECT category_id, product_id, price
FROM products
QUALIFY ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY price DESC) <= 2;
👉 Результат: по каждой категории вернутся только два товара с наибольшей ценой.
Этот приём делает запрос короче и понятнее, убирая необходимость во вложенных подзапросах. Если вы используете СУБД с поддержкой QUALIFY, берите на вооружение.DISTINCT ON (PostgreSQL):
SELECT DISTINCT ON (customer_id)
customer_id, order_id, created_at
FROM orders
ORDER BY customer_id, created_at DESC;
👉 Результат: по каждому customer_id вернётся только одна строка — с самым свежим заказом.
Очень компактная и быстрая альтернатива оконным функциям или JOIN-ам.DISTINCT ON, который позволяет взять первую строку в каждой группе по определённому полю.
SELECT DISTINCT ON (customer_id)
customer_id,
order_date,
amount
FROM orders
ORDER BY customer_id, order_date DESC;
🔎 Этот запрос вернёт последний заказ каждого клиента без лишних подзапросов или JOIN.
⚡ Работает очень быстро и удобно, если нужно найти «самый первый» или «самый последний» элемент в группе.
@sqlhubWINDOW FUNCTIONS — они считаются построчно, не сворачивая данные.
SELECT
customer_id,
order_date,
amount,
SUM(amount) OVER (
PARTITION BY customer_id
ORDER BY order_date
) AS running_total
FROM orders;
🔎 Здесь для каждого клиента мы получаем накопительную сумму по мере добавления заказов.
Оконные функции позволяют легко строить кумулятивные метрики, рейтинги и скользящие средние прямо в одном запросе.
@sqlhubON и фильтром в WHERE. На картинке это отлично показано.
Когда мы пишем LEFT OUTER JOIN, мы ожидаем, что слева попадут все строки. Но результат зависит от того, где именно мы накладываем фильтры.
✨ Пример:
У нас есть две таблицы:
- Левая: фигура + число
- Правая: число + фигура
Мы делаем LEFT OUTER JOIN.
1. Фильтр в ON
Если написать ON right_table.number = 1, то соединение будет проверять условие именно во время джойна. Это значит: строки слева сохранятся, даже если справа нет совпадений — просто будут NULL.
2. Фильтр в WHERE
Если написать WHERE left_table.number = 1, то фильтрация произойдёт уже после объединения. В этом случае строки, не прошедшие условие, полностью исчезнут из результата.
⚡ Почему это нужно знать?
- ON управляет логикой соединения.
- WHERE убирает строки после соединения.
- В OUTER JOIN это принципиальная разница: при фильтре в ON мы сохраним «пустые» строки, при фильтре в WHERE они будут удалены.
📌 Вывод:
- Если нужно оставить все строки из левой таблицы и лишь добавить совпадения справа - фильтр ставим в ON.
- Если хотим действительно отобрать только подходящие строки — фильтр в WHERE.
Именно поэтому в сложных запросах всегда спрашивай себя: фильтр — это часть логики соединения или это окончательное ограничение?
#SQL #joins #databases
Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
