Data Science: SQL и Аналитика данных
№ 6205468675 На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL. Сотрудничество: @niktwix Менеджер: @Spiral_Yuri
Показати більше📈 Аналітичний огляд Telegram-каналу Data Science: SQL и Аналитика данных
Канал Data Science: SQL и Аналитика данных (@pizdatascience) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 35 854 підписників, посідаючи 3 669 місце в категорії Технології та додатки та 17 882 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 35 854 підписників.
За останніми даними від 30 липня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -1 834, а за останні 24 години на 24, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 16.08%. Протягом перших 24 годин після публікації контент зазвичай збирає 10.63% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 5 790 переглядів. Протягом першої доби публікація в середньому набирає 3 827 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 0.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як sql, индекс, sqlite, строка, index.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“№ 6205468675
На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.
Сотрудничество: @niktwix
Менеджер: @Spiral_Yuri”
Завдяки високій частоті оновлень (останні дані отримано 31 липня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
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(*) оставь для случаев, когда реально нужно точное количество строк.