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 35 854 suscriptores, ocupando la posición 3 669 en la categoría Tecnologías y Aplicaciones y el puesto 17 882 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 35 854 suscriptores.
Según los últimos datos del 30 julio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -1 834, y en las últimas 24 horas de 24, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 16.08%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 10.63% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 5 790 visualizaciones. En el primer día suele acumular 3 827 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 31 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 *
FROM orders
WHERE user_id = 42
AND status = 'active';
Обычный индекс:
CREATE INDEX idx_orders_user_status
ON orders(user_id, status);
Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее.
Если чаще всего нужны только активные заказы, можно сделать partial index:
CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';
Такой индекс меньше, быстрее обновляется и лучше помещается в память. Планировщик сможет использовать его для запросов, где условие совпадает:
SELECT *
FROM orders
WHERE user_id = 42
AND status = 'active';
Индекс не обязан покрывать всю таблицу. Иногда лучший индекс - это индекс только по тем строкам, которые реально участвуют в горячих запросах.
Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAXSELECT *
FROM orders o
WHERE o.user_id IN (SELECT id FROM users WHERE active = true);
-- быстрее
SELECT *
FROM orders o
WHERE EXISTS (
SELECT 1
FROM users u
WHERE u.id = o.user_id AND u.active = true
);
EXISTS останавливается на первом совпадении и не тянет весь подзапрос в память. На больших данных разница может быть кратной.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX⏺️ связка Opus 4.8 и Composer 2.5 потратила около $1 400; ⏺️ Fable — примерно $20 000.Одинаковая задача, но почти пятнадцатикратная разница в цене. Во время разработки агенты столкнулись с до боли знакомыми командными проблемами: дублировали работу, конфликтовали при изменении одних и тех же файлов и избегали трогать ядро системы, даже когда без этого было невозможно двигаться дальше. Получается, ИИ уже способен за часы собрать сложный системный проект, но митинги, конфликты и страх ответственности он тоже автоматизировал 😂 #ai #rust #sqlite #agents #programming ➡️ https://cursor.com/blog/agent-swarm-model-economics 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX
SELECT *
FROM users
WHERE id NOT IN (
SELECT user_id
FROM banned_users
);
Но если banned_users.user_id содержит хотя бы один NULL, запрос может вернуть ноль строк.
Надёжнее использовать NOT EXISTS:
SELECT u.*
FROM users AS u
WHERE NOT EXISTS (
SELECT 1
FROM banned_users AS b
WHERE b.user_id = u.id
);
Причина в трёхзначной логике SQL: сравнение с NULL даёт UNKNOWN, а не TRUE или FALSE.
Правило простое: если подзапрос потенциально возвращает NULL, вместо NOT IN почти всегда выбирайте NOT EXISTS.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX🔶Какие навыки действительно проверяют на собеседованиях; 🔶Что должно быть в портфолио, чтобы его открывали работодатели; 🔶Почему многие резюме аналитиков сразу отправляются в отказ; 🔶Как искать работу без коммерческого опыта; 🔶Какие преимущества есть у кандидатов после 30, 40 и даже 50 лет; 🔶Какие ошибки чаще всего мешают получить первый оффер.Дополнительно на эфире разберем реальные примеры резюме и портфолио кандидатов, которые смогли пройти отбор. 🎁 ПОЛУЧИТЕ 3 КУРСА (PYTHON, SQL, PANDAS) В ПОДАРОК ЗА РЕГИСТРАЦИЮ НА ЭФИР! Эти курсы - база для того чтобы вкатиться в профессию! Если вы хотите войти в аналитику и перестать тратить время на лишнее обучение — этот урок поможет понять, на чем действительно стоит сосредоточиться. 🛎️Регистрируйтесь, эфир совсем скоро!
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(*) оставь для случаев, когда реально нужно точное количество строк.