Data Science: SQL и Аналитика данных
№ 6205468675 На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL. Сотрудничество: @niktwix Менеджер: @Spiral_Yuri
Show more📈 Analytical overview of Telegram channel Data Science: SQL и Аналитика данных
Channel Data Science: SQL и Аналитика данных (@pizdatascience) in the Russian language segment is an active participant. Currently, the community unites 32 533 subscribers, ranking 4 092 in the Technologies & Applications category and 19 679 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 32 533 subscribers.
According to the latest data from 24 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -476 over the last 30 days and by 32 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 17.82%. Within the first 24 hours after publication, content typically collects 16.16% reactions from the total number of subscribers.
- Post reach: On average, each post receives 5 796 views. Within the first day, a publication typically gains 5 257 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 0.
- Thematic interests: Content is focused on key topics such as sql, индекс, sqlite, строка, index.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“№ 6205468675
На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.
Сотрудничество: @niktwix
Менеджер: @Spiral_Yuri”
Thanks to the high frequency of updates (latest data received on 25 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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