Data Science. SQL hub

Oracle провела очередную волну сокращений, по сообщениям сотрудников, под увольнение попали примерно 3–4 тысячи человек. Отключения начались ещё до рассвета: около 4:00 сотрудникам стали закрывать доступ к внутренним системам, к 5:00–5:30 деактивировали Slack-аккаунты, а примерно в 6:00 разослали письма об увольнении. Некоторые люди приехали в офис, не успев проверить почту, и уже на месте обнаружили, что их бейджи больше не работают. Точный масштаб сокращений пока неясен, но отдельные команды, по словам сотрудников, потеряли около 10% состава. Число аккаунтов в рабочем Slack сократилось примерно на 3–4 тысячи. Это не первая крупная волна увольнений Oracle в этом году: весной компания уже провела масштабные сокращения.

Два клиента одновременно бронируют один номер. Как не продать его дважды? Обычная проверка «свободен ли номер?» может пропустить оба запроса: каждый успеет увидеть свободное время до сохранения чужой брони. В PostgreSQL можно запретить пересечения прямо в базе:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE bookings (
    room_id   INT NOT NULL,
    starts_at TIMESTAMPTZ NOT NULL,
    ends_at   TIMESTAMPTZ NOT NULL,

    CHECK (ends_at > starts_at),

    EXCLUDE USING gist (
        room_id WITH =,
        tstzrange(starts_at, ends_at, '[)') WITH &&
    )
);

Как это работает: • room_id WITH = — проверяем брони одного номера. • WITH && — запрещаем пересечение временных интервалов. • '[)' — начало включено, конец исключён. Брони 10:00–11:00 и 11:00–12:00 допустимы. • CHECK — окончание должно быть позже начала. Ограничение действует и при одновременных запросах. Две конфликтующие брони сохранить не получится: приложение должно обработать ошибку и сообщить, что время уже занято. Подходит для гостиниц, переговорных, аренды оборудования и записи к специалистам.

🔥 Один из лучших обучающих курсов на StepiK по SQL SQL можно знать годами и всё равно теряться, когда запрос внезапно начинает тормозить в проде. Этот курс про уровень, где ты не просто пишешь SELECT, а понимаешь, что происходит внутри MySQL, почему запрос работает медленно и как ускорить его без новых проблем. Здесь разбираются EXPLAIN, индексы, CTE, оконные функции, транзакции, аналитические паттерны, legacy SQL и работа с AI-ассистентами. Каждый урок - с практикой и реальными SQL-задачами на MySQL 8 с автопроверкой. После курса ты сможешь увереннее разбирать чужой код, находить узкие места и предлагать решения, которые действительно работают. Для подписчиков скидка - 49% в течение 2 суток: https://stepik.org/a/298827/

Как SQLite превращает числа в текст по две цифры за раз Обычное преобразование целого числа в строку извлекает цифры по одной с помощью деления на 10 и остатка % 10. В SQLite используется таблица sqlite3DigitPairs - строка длиной 200 байт со всеми парами от 00 до 99:

"00010203040506070809"
"10111213141516171819"
...
"90919293949596979899"

Алгоритм берёт две цифры сразу и копирует готовую пару по вычисленному индексу. Это сокращает количество делений и итераций при форматировании i64 и u64. Небольшая оптимизация внутри sqlite/src/util.c, которая особенно заметна на миллионах преобразований.

Почему PostgreSQL не использует индекс? Лайт объясняет РюкуОписание: Когда Seq Scan выгоднее индекса и как проверить план запроса через EXPLAIN ANALYZE. #sql #postgresql #deathnote

⚡️ DeepSeek выпустила V4.1 Flash Ноую модель уже раскатывают в веб-чате и мобильных приложениях. Прежние режимы - быстрый, экспертный и распознавание изображений свели в один: выбирать вручную больше ничего не нужно. Теперь одна модель ведёт и обычный диалог, и разбор картинок, и сложные вопросы. Сложность запроса она определяет сама, а зрение включает, когда на вход приходит изображение. По словам DeepSeek, V4.1 Flash обходит V4 Pro по качеству, стоимости и скорости. До выхода V4.1 Pro она возьмёт на себя все запросы, которые раньше уходили на V4 Pro. @ai_machinelearning_big_data #news #ai #ml

📌 Почему SQL работает именно так - заслуга Эдгара «Теда» Кодда В конце 1960-х базы данных напоминали лабиринты указателей. Чтобы найти запись, программисту приходилось понимать, как именно данные расположены внутри системы. Кодд предложил хранить данные в виде математических отношений - знакомых нам таблиц. В 1970 году он описал реляционную модель и основные операции: * σ - выбирает строки по условию, будущий WHERE * π - оставляет нужные столбцы, основа SELECT * ⋈ - соединяет связанные таблицы, будущий JOIN Ключевой идеей стала независимость данных. Пользователь описывает, какой результат ему нужен, а база сама решает, как его получить и где искать записи. SQL появился позже, но был построен на реляционной модели Кодда. Её принципы до сих пор лежат в основе большинства запросов к базам данных.

🧠 Как обучить нейросеть на Python с нуля Пошаговый разбор полного процесса: * подготовка и разделение данных * создание архитектуры модели * выбор функции потерь и оптимизатора * запуск обучения * проверка качества на новых данных * сохранение готовой модели Материал подойдёт новичкам, которые хотят перейти от теории к первой работающей нейросети и понять, что происходит внутри обучения. https://uproger.com/obuchit-nejroset-na-python/

💡 SQL-задача: почему запрос возвращает НЕПРАВИЛЬНЫЙ результат? Есть таблица платежей:

CREATE TABLE payments (
    user_id    BIGINT,
    paid_at    TIMESTAMP,
    amount     NUMERIC
);

Нужно найти последний платёж каждого пользователя. Разработчик пишет:

SELECT
    user_id,
    MAX(paid_at) AS paid_at,
    amount
FROM payments
GROUP BY user_id;

В некоторых СУБД запрос вообще не выполнится. А в тех, где выполнится, amount может оказаться вообще НЕ от последнего платежа. Почему? Потому что MAX(paid_at) вычисляется отдельно, а amount не обязан принадлежать той же строке. Например: user_id | paid_at | amount --------+--------------------+------- 1 | 2026-01-01 10:00 | 100 1 | 2026-02-01 10:00 | 900 Можно получить: 1 | 2026-02-01 10:00 | 100 Дата последняя, а сумма - от другой строки. Правильный вариант в PostgreSQL:

SELECT DISTINCT ON (user_id)
    user_id,
    paid_at,
    amount
FROM payments
ORDER BY user_id, paid_at DESC;

Или универсально через оконную функцию:

SELECT user_id, paid_at, amount
FROM (
    SELECT *,
           ROW_NUMBER() OVER (
               PARTITION BY user_id
               ORDER BY paid_at DESC
           ) AS rn
    FROM payments
) t
WHERE rn = 1;

Но тут есть ещё одна ловушка. Что будет, если у пользователя два платежа с одинаковым paid_at? Тогда результат становится недетерминированным. • Нужно добавить tie-breaker:

ORDER BY paid_at DESC, id DESC

Вот уже хороший вопрос для собеседования: Как получить последнюю строку из группы так, чтобы результат был детерминированным даже при одинаковых timestamp?

⚡️ MongrelDB-V - клиент для MongrelDB на языке V. Сам MongrelDB - open-source колоночная база на Rust с довольно необычным набором возможностей: - SQL через DataFusion - vector search и ANN - full-text search - MVCC - WAL - replication и CDC - шифрование AES-256-GCM - bitmap, MinHash, learned-range и другие индексы - встроенный и серверный режимы MongrelDB-V позволяет работать с этой базой из V через HTTP-клиент. Устанавливается обычной командой v install. Интересный проект для тех, кто хочет попробовать V не только для небольших CLI-утилит, но и для работы с SQL, поиском и AI-native retrieval. https://github.com/visorcraft/MongrelDB-V

Мы все еще здесь !

🔥 Tabularis - единое open-source приложение для работы с SQL Если приходится постоянно переключаться между разными клиентами для PostgreSQL, MySQL и SQLite, Tabularis собирает всё в одном desktop-приложении. Что умеет: - PostgreSQL, MySQL/MariaDB и SQLite из коробки - SQL notebooks с Markdown, результатами и графиками - визуальный конструктор запросов - Visual EXPLAIN с интерактивным разбором query plan - переменные между ячейками - MCP-сервер для AI-агентов - расширение поддержки других БД через плагины Подходит как единое рабочее место для аналитики, разработки и отладки SQL. Apache 2.0. https://github.com/TabularisDB/tabularis

Antares SQL Client Современный, быстрый и ориентированный на продуктивность SQL-клиент с акцентом на пользовательский опыт (UX). Текущие ключевые функции: - Подключение к нескольким базам данных одновременно. - Управление базами данных (добавление/редактирование/удаление). - Полное управление таблицами, включая индексы и внешние ключи. - Управление представлениями, триггерами, хранимыми процедурами, функциями и планировщиками (добавление/редактирование/удаление). - Современная и удобная система вкладок; держите открытыми все необходимые вкладки в вашем рабочем пространстве. - Заполнение тестовых данных в таблицах для генерации большого объема данных. - Подсказки и автозаполнение запросов. - История запросов: поиск по последним 1000 запросам. - Сохранение запросов, заметок или задач. - Поддержка SSH-туннелей. - Режим ручного выполнения транзакций. - Импорт и экспорт дампов баз данных. - Настраиваемые горячие клавиши. - Темная и светлая тема. - Темы редактора. https://github.com/antares-sql/antares

🔥 LatticeDB - локальная база для Graph RAG и памяти AI-агентов Проект объединяет в одном embedded-движке сразу три способа работы с данными: * граф связей * векторный поиск через HNSW * полнотекстовый поиск BM25 Вся база хранится в одном файле - без отдельного сервера и сложной конфигурации. Есть bindings для Python, TypeScript/Node.js и Go. Подходит для Graph RAG, agent memory и локальных knowledge-систем. https://readhacker.news/s/73wnt

✔️ OpenAI усилила защиту в Codex в ответ на инциденты удаления файлов Руководитель Codex Тибо Соттьё подвёл итог изменениям последних недель, которые снижают риск деструктивных действий Codex. 🟡Контекст

Месяц назад в сети появились жалобы на то, что GPT-5.6 в Codex делает с файлами то, о чем его не просили. Самый серьезный кейс - команда, которая должна была почистить за собой временные файлы, вместо этого удаляла файлы пользователя. В ходе разбора выяснили, что Codex создает временные папки и потом чистит их, и в редких случаях чистил неправильно - он переиспользовал под временную работу системную переменную окружения, а некорректная команда очистки затем указывала на настоящий домашний каталог вместо временной папки. Второй случай проще - модель удаляла или перезаписывала временный путь, не посмотрев, что там уже лежит.

По итогам расследования добавили дополнительную защиту на нескольких уровнях: 🟢Инструкции самой модели. Codex теперь обязан проверять, что именно он собирается удалить, заводить временные каталоги заново, не переиспользовать системные переменные окружения, выбирать обратимые действия и останавливаться, когда масштаб операции неясен. 🟢Проверки на исполнении. Механизм, который выявляет рискованные команды удаления и отправляет их на ревью, усилили. Если команду отклонили, модель направляют к более безопасному способу. 🟢Ужесточение Full access. Включить полный доступ случайно стало труднее, предупреждения переписали понятнее, а самые рискованные сочетания разрешений дополнительно ограничили. 🟢Обновленный Auto-review. Он стал лучше распознавать деструктивные действия. 🟢Тесты и обучение. OpenAI собрала условия и данные, воспроизводящие найденные сбои. Сейчас добавляются RL-задачи и грейдеры под эти риски, а деструктивные действия вычищаются из обучающих данных. 🟡Что советуют делать самим Обновлять Codex и работать в одном из режимов песочницы - Ask for approval или Approve for me. Full access включать только там, где среде можно доверять и откуда легко восстановиться. @ai_machinelearning_big_data #news #ai #ml

🔥 Python + AI без игрушечных демок. Курс для тех, кто хочет собирать рабочие системы. Stepik: «Python современный AI для разработчика и автоматизации задач» 63 урока, 382 шага, практика с кодом и автопроверкой. Внутри: RAG, tool calling, агенты, evals, MCP, Ollama, vLLM, pgvector + HNSW, безопасный text-to-SQL, prompt injection, кэш, очереди и sandbox для агентного кода. Плюс реальные автоматизации: почта, отчёты, боты, вебхуки и браузерные сценарии. Для тех, кто уже знает Python и хочет перейти к production AI. ⏳ 72 часа скидка 55% https://stepik.org/a/295921

🖥 Учим SQL не по учебнику, а расследуя преступления В Steam выходит Ghost in the SQL - детективная игра, где главный инструмент расследования не лупа и не допросы, а SQL-запросы. Чтобы найти подозреваемого, восстановить события или докопаться до нужной улики, придётся работать с базами данных, фильтровать информацию, связывать таблицы и писать запросы. Каждое дело постепенно знакомит с SQL через практику - от простых выборок до более сложного анализа данных. Обещают разные расследования - поджоги, убийства и другие преступления. Редкий случай, когда SELECT, JOIN и WHERE действительно помогают найти преступника. https://store.steampowered.com/app/5072430/Ghost_in_the_SQL_Data/

🌟 Turbovec: библиотека векторного поиска на основе гугловского TurboQuant Библиотека написана на Rust, есть привязки для Python, а в основе - TurboQuant, алгоритм сжатия векторов, который Google описали в статье, принятой на ICLR 2026.

Сама библиотека к Google отношения не имеет, это независимая реализация чужого алгоритма.

🟡Turbovec сжимает данные примерно в восемь раз Коллекция из 10 миллионов документов, занимающая в исходном виде 31 гигабайт, умещается в 4. Поиск при этом, как утверждает автор, идёт быстрее, чем в FAISS - одного из самых распространённых инструментов в этой области. По замерам turbovec обгоняет FAISS в среднем в 3,4-3,5 раза при 4-битном сжатии и на 20-26% при 2-битном, в зависимости от железа. 🟡Удобные мелочи Индекс не нужно предварительно обучать - векторы просто добавляются по мере поступления. Сохранение инкрементальное, на диск уходит только то, что изменилось с прошлого раза, поэтому даже на большом индексе это занимает миллисекунды. Поиску можно передать список разрешённых документов - скажем, чтобы пользователь видел только свои файлы. Удаление работает по постоянным идентификаторам, ссылки на записи не плывут. Тем, кто уже сидит на LangChain, LlamaIndex, Haystack или Agno, автор предлагает готовые адаптеры - меняется одна строка импорта, остальной код остаётся как был. 📌Лицензирование: MIT License 🖥 Github @ai_machinelearning_big_data #AI #ML #VectorSearch #TurboQuant #Rust

SQL как ремесло и SQL как инструмент бизнеса — разные навыки Владеть SQL — значит написать корректный запрос под любую задачу. Работать продуктовым аналитиком — значит понять, какую задачу решает заказчик, и превратить выгрузку в ответ на его вопрос. Первое проверяется тестом на соединениях таблиц, второе — на реальных проектах. 25 августа karpovꓸcourses проводят бесплатный вебинар про этот второй пласт. На реальных задачах разберут: — какие вопросы задать до запроса, чтобы выгрузка отвечала на задачу заказчика; — как проверять данные после выгрузки и находить ошибки, которые SQL не подсвечивает; — типичные ловушки в расчетах, из-за которых технически верный запрос дает неверный ответ; — как переводить таблицу с цифрами в вывод для бизнеса. Разбирает Дмитрий Бакаев — продуктовый аналитик в «Передовых Платежных Решениях» и выпускник курса «Аналитик данных» karpovꓸcourses. Вопросы принимает в эфире. За регистрацию сразу приходит карьерный гайд по профессиям в аналитике, после эфира — запись вебинара Регистрируйтесь по ссылке — https://clc.to/erid_2W5zFJogLHX    Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFJogLHX