Data Science: SQL и Аналитика данных
№ 6205468675 На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL. Сотрудничество: @niktwix Менеджер: @Spiral_Yuri
Ko'proq ko'rsatish📈 Telegram kanali Data Science: SQL и Аналитика данных analitikasi
Data Science: SQL и Аналитика данных (@pizdatascience) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 32 533 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 4 092-o'rinni va Rossiya mintaqasida 19 679-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 32 533 obunachiga ega bo‘ldi.
24 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -476 ga, so‘nggi 24 soatda esa 32 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 17.82% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 16.16% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 5 796 marta ko‘riladi; birinchi sutkada odatda 5 257 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 0 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent sql, индекс, sqlite, строка, index kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“№ 6205468675
На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.
Сотрудничество: @niktwix
Менеджер: @Spiral_Yuri”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 25 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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