Data Science: SQL и Аналитика данных
№ 6205468675 На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL. Сотрудничество: @niktwix Менеджер: @Spiral_Yuri
Mostrar más📈 Análisis del canal de Telegram Data Science: SQL и Аналитика данных
El canal Data Science: SQL и Аналитика данных (@pizdatascience) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 37 645 suscriptores, ocupando la posición 3 579 en la categoría Tecnologías y Aplicaciones y el puesto 17 014 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 37 645 suscriptores.
Según los últimos datos del 02 julio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -638, y en las últimas 24 horas de 12, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 12.60%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 12.59% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 4 739 visualizaciones. En el primer día suele acumular 4 737 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 0.
- Intereses temáticos: El contenido se centra en temas clave como sql, индекс, sqlite, строка, index.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“№ 6205468675
На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.
Сотрудничество: @niktwix
Менеджер: @Spiral_Yuri”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 03 julio, 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.
SELECT COUNT(*) > 0
FROM orders
WHERE user_id = 42;
База может пройти по всем подходящим строкам, чтобы посчитать количество.
Лучше:
SELECT EXISTS (
SELECT 1
FROM orders
WHERE user_id = 42
);
EXISTS останавливается сразу, как только нашел первую подходящую строку. Для больших таблиц это может быть заметно быстрее, особенно если есть индекс по условию:
CREATE INDEX idx_orders_user_id ON orders(user_id);
Если тебе нужен ответ “есть или нет”, используй EXISTS. COUNT(*) оставь для случаев, когда реально нужно точное количество строк.
SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id;
Лучше так:
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
);
Почему это сильный приём:
EXISTS останавливается, как только находит первое совпадение
не нужно тащить лишние строки
не нужно потом убирать дубли
логика запроса становится честной - ты проверяешь наличие, а не собираешь мусор
Это один из самых частых hidden performance fixes в SQL. Если видишь DISTINCT, сразу спрашивай себя: он тут реально нужен или просто маскирует плохую логику JOIN.
➡️ https://github.com/FalkorDB/QueryWeaver
сё про Data Science
🇷🇺 Читайте нас в MAXSELECT
cardholder_id,
timestamp,
amount,
merchant_id,
timestamp - LAG(timestamp) OVER w AS time_since_last,
CASE WHEN merchant_id <> LAG(merchant_id) OVER w
THEN 'changed' ELSE 'same' END AS merchant_change,
sum(amount) OVER (
PARTITION BY cardholder_id
ORDER BY timestamp
RANGE BETWEEN INTERVAL '24 hours' PRECEDING AND CURRENT ROW
) AS running_24h_total,
ROW_NUMBER() OVER (
PARTITION BY cardholder_id, date(timestamp)
ORDER BY timestamp
) AS tx_of_day
FROM transactions
WINDOW w AS (PARTITION BY cardholder_id ORDER BY timestamp)
ORDER BY cardholder_id, timestamp;
И после этого уже прогонять проверки с помощью WHERE:
SELECT *
FROM tx_with_windows
WHERE tx_of_day >= 5
AND time_since_last < INTERVAL '60 seconds'
AND merchant_change = 'changed';
Главное — не переусердствовать и помнить, что каждый сигнал по отдельности, как правило, ничего не доказывает: и обычному человеку может понадобиться снять деньги с карты несколько раз подряд или сбегать в магазин посреди ночи. Чтобы отсеять честных пользователей от мошенников, нужно смотреть на несколько параметров в совокупности.
Всё про Data Science
🇷🇺 Читайте нас в MAX
SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id;
Лучше так:
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
);
Почему это сильный приём:
EXISTS останавливается, как только находит первое совпадение
не нужно тащить лишние строки
не нужно потом убирать дубли
логика запроса становится честной - ты проверяешь наличие, а не собираешь мусор
Это один из самых частых hidden performance fixes в SQL. Если видишь DISTINCT, сразу спрашивай себя: он тут реально нужен или просто маскирует плохую логику JOIN.
Всё про Data Science
🇷🇺 Читайте нас в MAXNOTIFY, например.
Да, действительно, и, если вам нужно мониторить изменения в небольшой, не слишком часто обновляющейся таблице, то это отличный вариант. Но дело в том, что все уведомления NOTIFY падают в одну очередь, и если таких уведомлений много, то они затормозят работу всей БД.
Кроме того, их размер ограничен 8000 байтов, чего может быть недостаточно. А еще, если сервис-получатель был по какой-то причине не доступен и сообщение не дошло, повторное через NOTIFY не отправляется — то есть данные просто потеряются.
В общем, не идеальный вариант.
➡️ Альтернатива — это настроить Write-Ahead Log или WAL, чтобы получать уведомления из него.
Спойлер: этот вариант тоже не идеальный. Как минимум, придется повозиться:
⏺️Изменить wal_level на logical со стандартного replica — так он начнет делать более подробные записи о том, как и что конкретно изменилось в базе.
⏺️Создать publications (то есть, расписать, какие таблицы и действия вы хотите отслеживать) и репликационный слот (то есть отдельную копию WAL, которая гарантирует, что никакие важные данные из лога не удалятся, пока уведомление не будет отправлено).
⏺️Создать listener, который будет получать уведомления и перенаправлять их дальше — в очередную таблицу, в приложение или мессенджер. Или вообще распечатать.
➡️ Но если вам нужно настроить отправку уведомлений и другие способы не подходят, это может быть вполне рабочее решение. Как воплотить его в жизнь, по шагам описано в подробном (очень подробном) гайде.
Всё про Data Science
🇷🇺 Читайте нас в MAX
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
