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