Data Science: SQL и Аналитика данных
№ 6205468675 На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL. Сотрудничество: @niktwix Менеджер: @Spiral_Yuri
Больше📈 Аналитический обзор Telegram-канала Data Science: SQL и Аналитика данных
Канал Data Science: SQL и Аналитика данных (@pizdatascience) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 32 528 подписчиков, занимая 4 092 место в категории Технологии и приложения и 19 679 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 32 528 подписчиков.
Согласно последним данным от 23 октября, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -484, а за последние 24 часа — 31, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 17.78%. В первые 24 часа после публикации контент обычно набирает 16.17% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 5 778 просмотров. В течение первых суток публикация набирает 5 257 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 0.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как sql, индекс, sqlite, строка, index.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“№ 6205468675
На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.
Сотрудничество: @niktwix
Менеджер: @Spiral_Yuri”
Благодаря высокой частоте обновлений (последние данные получены 24 октября, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
CREATE TABLE points (
id INT PRIMARY KEY,
x INT,
y INT
);
INSERT INTO points VALUES
(1, 1, 1),
(2, 99, 99),
(3, 50, 50),
(4, 52, 52);
Напишите запрос, который найдёт все пары точек с минимальным расстоянием по прямой с учётом переходов через границы.
Условия:
⏺️ точку нельзя сравнивать с собой;
⏺️ пары (1, 2) и (2, 1) считаются одной;
⏺️ при одинаковом минимуме выведите все пары;
⏺️ результат: id1, id2, distance.
Обычная формула расстояния без учёта границ даст неверный ответ
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX.git/objects, refs и logs, поэтому восстановление через обычный Git оказалось невозможно.
Checkpoint Claude Code здесь не обязательно спасает, потому что изменения, сделанные через Bash/PowerShell, могут не попадать в механизм rewind.
➡️ Источник: https://cybersecuritynews.com/claude-code-agent-file-deletion/
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAXCREATE TABLE accounts (
id int PRIMARY KEY,
balance int
);
CREATE TABLE operations (
account_id int,
amount int
);
INSERT INTO accounts VALUES (1, 100);
INSERT INTO operations VALUES
(1, 10),
(1, 20);
UPDATE accounts a
SET balance = a.balance + o.amount
FROM operations o
WHERE o.account_id = a.id;
Многие ответят 130, но PostgreSQL обновит строку только один раз.
Результатом может стать 110 или 120. Если целевая строка соединяется с несколькими строками из FROM, PostgreSQL использует одну из них, но какую именно, не гарантируется.
➡️ Правильный вариант:
UPDATE accounts a
SET balance = a.balance + x.total
FROM (
SELECT account_id, SUM(amount) AS total
FROM operations
GROUP BY account_id
) x
WHERE x.account_id = a.id;
Теперь каждой строке accounts соответствует ровно одна строка источника, а баланс станет 130.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAXsqlite3DigitPairs - строка длиной 200 байт со всеми парами от 00 до 99:
"00010203040506070809" "10111213141516171819" ... "90919293949596979899"Алгоритм берёт две цифры сразу и копирует готовую пару по вычисленному индексу. Это сокращает количество делений и итераций при форматировании i64 и u64. Небольшая оптимизация внутри sqlite/src/util.c, которая особенно заметна на миллионах преобразований. #SQL #PostgreSQL #Database 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX
CREATE TABLE payments (
id int,
amount int
);
INSERT INTO payments VALUES
(1, 100),
(2, 100),
(3, 200);
SELECT
id,
amount,
SUM(amount) OVER (ORDER BY amount) AS total
FROM payments
ORDER BY id;
Многие ожидают:
1 | 100 | 100 2 | 100 | 200 3 | 200 | 400
Но результат будет другим: 1 | 100 | 200 2 | 100 | 200 3 | 200 | 400 По умолчанию PostgreSQL использует окно RANGE ... CURRENT ROW. Строки с одинаковым amount считаются равными соседями и попадают в окно вместе. Для построчного накопления нужно указать ROWS: SUM(amount) OVER ( ORDER BY amount, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW )#SQL #PostgreSQL #Database 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX
SELECT, а потом уменьшить его отдельным запросом, два покупателя могут одновременно увидеть последнюю единицу.
В PostgreSQL проверку и списание можно объединить:
UPDATE products SET stock = stock - 1 WHERE id = 42 AND stock > 0 RETURNING id, stock;
Что получится при одновременных запросах:
• Первый покупатель уменьшит остаток с 1 до 0.
• Второй дождётся освобождения строки, и условие stock > 0 будет проверено повторно.
• Его запрос не обновит строку и ничего не вернёт — товар закончился.
Так работает обычный уровень изоляции PostgreSQL READ COMMITTED.
Добавьте защиту от отрицательных остатков:
ALTER TABLE products ADD CONSTRAINT stock_nonnegative CHECK (stock >= 0);
Списание остатка и создание заказа выполняйте в одной транзакции, чтобы при ошибке заказа изменение остатка тоже откатилось.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX⏺️ локальный MCP-клиент; ⏺️ Agentic RAG; ⏺️ финансовый аналитик; ⏺️ voice agent; ⏺️ Deep Researcher; ⏺️ RAG по документам и видео; ⏺️ генератор синтетических данных; ⏺️ shared memory для Claude Desktop и Cursor.🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX
SELECT, JOIN и WHERE действительно помогают найти преступника.
➡️ https://store.steampowered.com/app/5072430/Ghost_in_the_SQL_Data/
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX
SELECT COUNT(*) FROM events;
На большой таблице это может читать миллионы строк.
Для быстрой оценки можно взять статистику PostgreSQL:
SELECT reltuples::bigint
FROM pg_class
WHERE relname = 'events';
reltuples хранит примерную оценку количества строк, которую PostgreSQL обновляет после ANALYZE и VACUUM.
Это полезно для админок, мониторинга, дашбордов и проверок вида «в таблице примерно 10 млн или 100 млн строк?», где абсолютная точность не нужна.
А если нужна актуальная оценка:
ANALYZE events;
После этого reltuples станет ближе к реальному количеству строк.
На таблицах в сотни миллионов строк разница между мгновенной оценкой и настоящим COUNT(*) может быть огромной.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAXNested Loop и в итоге прогнать миллионы сравнений.
В PostgreSQL быстро обновить статистику можно так:
ANALYZE users;
А проверить, насколько оценки оптимизатора отличаются от реальности:
EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM users
WHERE status = 'active';
Смотри на разницу между rows= и actual rows=.
Если PostgreSQL ожидал 100 строк, а реально получил 500 000, проблема может быть не в индексе, а в плохой статистике.
Особенно часто это всплывает после массовых INSERT, UPDATE, импорта данных или резкого изменения распределения значений.
🫡 Всё про Data Science
🇷🇺 Читайте нас в MAX