SQL Ready | Базы Данных

Совет на 2027 год — переходите в ML. Пока обычные разрабы конкурируют с ИИ-копилотами, ML-инженеры эти самые нейронки создают. В эпоху нейростей это самые востребованые люди в мире программирования. Зарплаты мидлов начинаются от 250 000 ₽, а у сеньоров в BigTech доходят до 700 000 ₽. А чтобы освоить его всего за 4 месяца без лишней суеты — изучите канал Марка Миргалеева. Он помог 20+ ученикам найти работу от 250к в ML/NLP/AI-агентах На канале вы найдёте: — Всё про самые востребованные стеки(Python, ИИ-агенты, NLP) и почему математика — это не страшно, если учить только нужное. — Как оформить резюме, чтобы оно пролетало через любые LLM-фильтры и ATS-системы прямо к тимлидам. — Скрипты переговоров, которые помогли его ученикам прыгнуть с 0 до 360к всего за 8 месяцев. Во времена острой нехватки ML-разработчиков, это лучшее время, чтобы перекатиться. Переходи и изучай: https://t.me/+TwxQ8W6MF6hhY2My

📂 Напоминалка по DB Sharding! Шардинг помогает масштабировать базу данных, распределяя данные между несколькими серверами. На картинке — основные стратегии партиционирования и шардинга. Например, key-based sharding использует hash-функцию для равномерного распределения записей, а range-based sharding делит данные по диапазонам значений. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

LAG() в SQL — сравниваем строку с предыдущей без JOIN! Оконная функция LAG() позволяет получить значение из предыдущей строки внутри группы. Это один из самых полезных инструментов для аналитики, логов и временных рядов. Таблица: payments(id, user_id, amount, created_at) Посмотрим предыдущий платёж каждого пользователя:

SELECT
    user_id,
    amount,
    LAG(amount) OVER (
        PARTITION BY user_id
        ORDER BY created_at
    ) AS prev_amount
FROM payments;

LAG() сдвигает значение на одну строку назад внутри окна пользователя. Теперь можно сразу посчитать разницу между текущим и прошлым платежом:

SELECT
    user_id,
    amount,
    amount - LAG(amount) OVER (
        PARTITION BY user_id
        ORDER BY created_at
    ) AS diff
FROM payments;

Так удобно анализировать рост, падение и аномалии в данных без дополнительных JOIN. Можно находить моменты изменения значения, например смену статуса:

SELECT *
FROM (
    SELECT
        user_id,
        status,
        LAG(status) OVER (
            PARTITION BY user_id
            ORDER BY created_at
        ) AS prev_status
    FROM user_logs
) t
WHERE status <> prev_status;

Запрос покажет только строки, где статус изменился относительно предыдущего события. 🔥 LAG() часто используют для анализа трендов, поиска изменений, расчёта дельт и работы с временными рядами. ➡️ SQL Ready | #практика

Замечал странную штуку: дел не так уж много, но любое – как будто через сопротивление? Не то чтобы лень. Просто не делается и все тут! Зато видосики на Ютубе залетают на ура... Попался годный разбор, советую посмотреть, если тоже чувствуешь, что превращаешься в апатичного зомби 👉🏼 https://t.me/Manifestans Мысль, которая зашла: когда перестаешь понимать "чего хочу Я", даже нормальная жизнь ощущается, как каторга. Кликай сюда, чтобы разобраться, что с тобой происходит и как снова начать испытывать ощущение, что ты живешь, а не существуешь.

🐱 Awesome Postgres — огромная база всего, что связано с PostgreSQL! В этом репозитории собраны лучшие инструменты, библиотеки, GUI-клиенты, ORM, статьи, курсы и сервисы для работы с PostgreSQL. По сути — это подборка всего полезного для backend-разработчика и DBA в одном месте. Внутри есть материалы не только по базовой работе с БД, но и по мониторингу, репликации, производительности, миграциям и архитектуре.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Исключающие ограничения: гарантия отсутствия пересечений на уровне БД! Проверять пересекаются ли интервалы через SELECT перед INSERT — классическая ошибка, которая ломается при конкурентных транзакциях.

SELECT 1
FROM bookings
WHERE room_id = 101
AND start_at < $end
AND end_at > $start;

Даже если проверка есть, два параллельных запроса могут пройти её одновременно и записать конфликтующие данные:

CREATE EXTENSION IF NOT EXISTS btree_gist;

PostgreSQL решает это на уровне ограничений через exclusion constraint, который работает корректно даже при конкуренции:

ALTER TABLE bookings
ADD CONSTRAINT no_overlap
EXCLUDE USING gist (
  room_id WITH =,
  tsrange(start_at, end_at) WITH &&
);

🔥 exclusion constraint — это способ переложить сложную логику (пересечения, диапазоны, уникальность по условиям) с приложения на уровень СУБД с полной защитой от состояния гонки. ➡️ SQL Ready | #совет

Давайте внедрим ИИ! 14 мая МТС Web Services проводит мероприятие для системных-аналитиков в Москве и онлайн, где эксперты из MWS, Orion Soft в формате докладов и открытого диалога с гостями обсудят: • Ждёт ли нас трансформация профессии и как ИИ уже влияет на роль системных аналитиков? • Как Cursor можно встроить в повседневную работу системного аналитика? • Как вписать новую технологию в общую архитектуру решения? Когда: 14 мая в 18:00 Офлайн в Москве + онлайн-трансляция. Количество офлайн-мест ограничено. Для участия зарегистрируйтесь по ссылке

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

📂 Напоминалка по тому, как работает PostgreSQL! Например, каждое подключение создаёт отдельный процесс, а любые изменения сначала попадают в WAL, и только потом гарантированно пишутся в данные. На картинке — базовая архитектура: подключения и backend-процессы, shared memory, background и auxiliary процессы и физическое хранение. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Диапазоны как тип данных: убираем двойные условия и баги! Когда работаешь с интервалами, обычно пишут два условия, и почти всегда где-то ошибаются с границами:

WHERE created_at <= now()
AND shipped_at > now()

Такой код легко сломать и плохо масштабируется:

tstzrange(created_at, shipped_at)

PostgreSQL имеет встроенные range-типы, которые позволяют хранить и сравнивать интервалы как единое значение. tstzrange — для timestamptz, tsrange — для timestamp:

@> now()

Оператор @> проверяет содержит ли диапазон значение, заменяя сразу два условия. По умолчанию границы [ ) — аналог created_at <= x AND shipped_at > x:

CREATE INDEX ON orders USING GIST (tstzrange(created_at, shipped_at));

С GiST-индексом такие запросы работают эффективно даже на больших объёмах. 🔥range-типы — это способ убрать класс ошибок с датами и упростить сложную логику. ➡️ SQL Ready | #совет

Отклики, после которых зовут на собеседования Главный фокус команды ии-ассистента Софи: 1. Ребята переписали парсер - теперь собирают вакансии из 110+ источников: Telegram, Хабр, LinkedIn и другие. 2. Параллельно сделали умный мэтчер - Софи теперь показывает не всё подряд, а то, что подходит именно вам (локация, стек, грейд + обучение на фидбэке юзеров). На этом строится основа автооткликов - быстрых, точных и стабильных. Следующий шаг - откалибровать мэтчер до точности 80%+, но это невозможно без реальных пользователей. Поэтому в ближайшие дни они открывают доступ к бесплатному тестированию. Мест будет немного, так как фокус на качестве. ➡️Если хочешь попасть - подписывайся на канал, там будет анонс о наборе.

😍 SQL PostgreSQL Course — информативный курс по SQL с практикой! Это структурированное обучение по PostgreSQL: от базовых запросов до JOIN’ов, подзапросов и проектирования базы данных. Материал выстроен последовательно, поэтому легко идти шаг за шагом и не теряться в теме. Здесь есть практика с заданиями и ответами, за счёт чего обучение закрепляется.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

😎 SQL Server Kit — практическая база инструментов и материалов! Репозиторий представляет собой обширную коллекцию скриптов, статей, рекомендаций и утилит для администрирования и разработки на SQL. Внутри собраны решения для диагностики производительности, оптимизации запросов, мониторинга, резервного копирования, работы с индексами и анализа состояния базы данных. Также представлены ссылки на проверенные источники и лучшие практики работы с СУБД.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Дубликаты после JOIN — откуда берутся и как контролировать! Одна из частых проблем — внезапное размножение строк после JOIN. Это базовое поведение, если не учтена кардинальность связей. Таблицы:

orders(id, customer_id, amount)
payments(id, order_id, status)

Задача: получить заказы с информацией об оплате.

SELECT 
    o.id,
    o.amount,
    p.status
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

Если у одного заказа несколько платежей — в результат попадёт несколько строк. Фактически вы получаете по одной строке на каждое совпадение orders — payments. То есть один заказ повторится столько раз, сколько у него записей в payments. Для связи 1:N это абсолютно ожидаемо. Где начинаются проблемы — агрегация:

SELECT 
    COUNT(*) AS total_orders
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

Здесь COUNT(*) считает строки уже после JOIN, а не заказы. Если у заказа 3 платежа — он попадёт в счёт 3 раза. Это одна из самых частых причин кривых метрик. Корректный вариант:

SELECT 
    COUNT(DISTINCT o.id) AS total_orders
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

Так считаются уникальные заказы, независимо от числа платежей. Но важно помнить, что DISTINCT — это дополнительная операция, и на больших объёмах она может стоить дорого. И отдельный момент, если вам нужно просто количество заказов без условий по payments, JOIN здесь вообще лишний. Лучше контролировать кардинальность до JOIN Если задача — проверить наличие успешной оплаты, проще и дешевле использовать EXISTS:

SELECT 
    o.id,
    o.amount
FROM orders o
WHERE EXISTS (
    SELECT 1
    FROM payments p
    WHERE p.order_id = o.id
      AND p.status = 'success'
);

EXISTS работает как semi-join: он проверяет факт наличия строки, но не тянет её в результат. За счёт этого одна строка заказа остаётся одной строкой. Если JOIN всё-таки нужен — агрегируем заранее:

SELECT 
    o.id,
    o.amount,
    COALESCE(p.has_success, 0) AS has_success
FROM orders o
LEFT JOIN (
    SELECT
        order_id,
        MAX(CASE WHEN status = 'success' THEN 1 ELSE 0 END) AS has_success
    FROM payments
    GROUP BY order_id
) p ON p.order_id = o.id;

Здесь мы сначала приводим payments к одной строке на order_id, и только потом делаем JOIN. После этого результат становится понятным: одна строка на заказ, без раздувания. Типичная ошибка:

GROUP BY o.id, o.amount, p.status

Это не решит проблему. Такой GROUP BY просто фиксирует текущую детализацию. Если у заказа было несколько статусов — строки никуда не денутся. 🔥 JOIN не создаёт дубликаты сам по себе. Он возвращает строки в соответствии с числом совпадений по условию ON. Если после JOIN строк стало больше — значит реальная связь между таблицами не 1:1, а 1:N или даже N:M. ➡️ SQL Ready | #практика

Совет на всю жизнь — начните изучать вайбкодинг. Нейронки уже собирают проекты от идеи до релиза, пишут код, находят и исправляют баги лучше команды айтишников. Это сэкономит вам десятки часов работы. А чтобы научиться вайбкодить и не совершать ошибки - читайте канал AI-архитектор, где есть: ➖Инструкции по Antigravity и n8n. ➖Связки, которые приносят от 100 000 ₽ за проект ➖Реальный опыт программиста и вайбкодера, который настраивает автоматизацию ИИ для гос. компаний. Подписывайтесь и смотрите в закрепе, как за 2 дня собрать ИИ-автоматизацию без единой строчки кода: https://t.me/+eBc7ivvcY34xZTli

☕️ Полезную статью нашёл на Хабре: «Ваш RAG не умеет думать. А мой умеет»! В этой статье: • Разбирается, почему классические RAG-системы на базе векторных БД часто ограничиваются поверхностным поиском; • Показан подход HippoRAG 2, где память и связи между фактами организованы ближе к графовой модели; • Объясняется, как эволюционирует работа с данными; • Рассматривается, как это влияет на SQL/NoSQL слой, архитектуру хранения и построение более осмысленных запросов к данным.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья

Использование data-modifying CTE для цепочек операций в одном запросе! Обычно изменения и чтение делают разными запросами, что создаёт лишние round-trip и риск рассинхронизации данных между операциями:

UPDATE orders
SET status = 'processing'
WHERE id = 123
RETURNING *;

RETURNING уже даёт доступ к изменённым строкам, но data-modifying CTE позволяет пойти дальше и использовать их в следующих шагах:

WITH updated AS (...)

CTE фиксирует результат изменения и гарантирует, что последующие операции работают с тем же набором строк в рамках одного statement:

INSERT INTO audit_log (order_id, new_status)
SELECT id, status
FROM updated;

Теперь можно атомарно обновить данные и сразу записать аудит, отправить в очередь или выполнить дополнительную логику без повторных SELECT. 🔥 data-modifying CTE — это способ строить сложные, но безопасные цепочки операций внутри одного SQL-запроса. ➡️ SQL Ready | #совет

ПАРУ СЛОВ О ChaGPT 5.5 (Spud) Последние дни активно тестирую новую модель. Если коротко:

— Плюсы: кодинг, миллион токенов контекста и агентский режим — Минусы: логические ошибки, нужно присматривать в сложных задачах

Больше всего зацепила именно работа агента. Решил проверить его на своей «боли» — навел порядок в подписках Telegram. В последнее время лента превратилась в бесконечный шум с постами об одном и том же. Дал задачу нейронке: просмотреть мои подписки, убрать лишнее и оставить только тех, кто пишет про реальный опыт, автоматизацию и внедрение ИИ в работу. Модель сама просканировала каналы и собрала отличную подборку. Результат получился реально адекватным, поэтому делюсь этой подборкой. Авторы, которые каждый день пишут полезные об IT и AI доступно и интересно. Подписывайтесь на лучших Tech-специалистов https://t.me/addlist/81ejyxxH4rM0ZDIy

Проверяем дубликаты и считаем уникальные значения! В больших таблицах важно быстро находить повторяющиеся записи и понимать, сколько уникальных элементов. Это полезно для контроля качества данных и аналитики. Создадим таблицу пользователей:

CREATE TABLE users (
    user_id INT,
    email VARCHAR(100)
);

INSERT INTO users VALUES
(1, 'alice@mail.com'),
(2, 'bob@mail.com'),
(3, 'alice@mail.com'),
(4, 'carol@mail.com'),
(5, 'bob@mail.com');

Запрос для выявления дубликатов и подсчёта уникальных email:

SELECT email, COUNT(*) AS cnt,
       CASE WHEN COUNT(*)>1 THEN 'Duplicate' ELSE 'Unique' END AS status
FROM users
GROUP BY email;

Функция COUNT() + GROUP BY группирует одинаковые значения, а CASE сразу классифицирует их как дубликаты или уникальные. Результат:

email           | cnt | status
-----------------------------
alice@mail.com  | 2   | Duplicate
bob@mail.com    | 2   | Duplicate
carol@mail.com  | 1   | Unique

🔥 Это простой способ контролировать качество данных, выявлять ошибки и готовить отчёты для команды. ➡️ SQL Ready | #практика

⚡️ Вышло большое обновление популярного курса- AI агенты, которые реально работают в проде! Вы всё ещё пишете обёртки над ChatGPT и называете это «AI-продуктом»? Пока вы промптите - рынок переходит на агентные системы. Те, что принимают решения, ходят в API, работают с Postgres и Redis, управляют браузером через Playwright. И 90% таких систем ломаются между ноутбуком и продом. AI Agents Engineering - курс, который закрывает этот разрыв. LangGraph, AutoGen, Computer Use, LLMOps. 8 модулей, 120+ шагов - от архитектуры до деплоя в Docker. На выходе: реальный опыт на большой практической базе, а production-агент и навыки, за которые уже платят. 👉 48 часов действует скидка на курс 55 процентов: https://stepik.org/a/276971/