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

👨👨👨👨👨👨👨👨👨👨 Каналы с IT мероприятиями Подписывайся, чтобы не пропустить 🤘 1. IT мероприятия для стажеров и студентов 2. IT мероприятия по РФ 3. IT мероприятия и хакатоны 4. Бесплатные IT мероприятия 5. IT мероприятия онлайн 6. IT мероприятия Москва 7. IT мероприятия Санкт-Петербург

PostgreSQL может избежать полной сортировки таблицы при ORDER BY ... LIMIT! Большинство думает, что ORDER BY всегда сортирует вообще всю таблицу. Но в PostgreSQL для LIMIT есть отдельная оптимизация — Top-N Heap Sort.

SELECT *
FROM orders
ORDER BY created_at DESC
LIMIT 10;

Если нужен только top-10 результат, PostgreSQL не обязан сортировать миллионы строк полностью. Вместо этого он держит в памяти только N лучших строк во время scan. Это видно прямо в execution plan:

Sort Method: top-N heapsort

Особенно интересно становится на огромных таблицах, где полный sort мог бы уйти на диск:

SET work_mem = '4MB';

EXPLAIN ANALYZE
SELECT *
FROM events
ORDER BY created_at DESC
LIMIT 50;

Даже при маленьком work_mem PostgreSQL может избежать полной сортировки всех строк и работать заметно быстрее именно благодаря оптимизации Top-N. А если добавить подходящий индекс:

CREATE INDEX idx_events_created_at
ON events (created_at DESC);

🔥 PostgreSQL вообще сможет обойтись без Sort и просто сделать Index Scan в нужном порядке. ➡️ SQL Ready | #совет

Кажется, аналитика подошла к моменту больших изменений. Ещё недавно подготовка отчётов занимала дни: данные собирались вручную, цифры перепроверялись, а бизнес слишком долго ждал ответы. Сегодня искусственный интеллект меняет сам подход к работе с данными — делает аналитику быстрее, проще и доступнее. 3 июня Visiology проведёт большой онлайн-эфир Cortex LIVE о новом поколении аналитики. На бесплатном эфире покажут: — как ускорить получение аналитики — как сократить объём ручной работы — как быстрее находить ответы для бизнеса — как компании уже меняют подход к работе с данными Без сложной теории — только реальные примеры и практические сценарии. Если вы работаете с аналитикой, отчётностью или управлением, этот эфир точно стоит посмотреть. До мероприятия осталось совсем немного времени — успейте зарегистрироваться заранее, чтобы не пропустить эфир.

📂 Напоминалка по оптимизации баз данных! Например, индексы ускоряют поиск данных, а репликация помогает распределять нагрузку и повышать отказоустойчивость. На картинке — 9 основных подходов для улучшения производительности базы данных, которые полезно держать под рукой. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

❤️ SQL DEV — большая база для изучения SQL и PostgreSQL! Здесь собрано огромное количество материалов по SQL: запросы, JOIN’ы, подзапросы, оконные функции, индексы, оптимизация и работа с PostgreSQL. Репозиторий отлично подходит как для изучения базы, так и для углубления в более сложные темы. Особенно полезно то, что здесь много практических примеров и разборов реальных SQL-конструкций.

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

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

Почему NOT IN может вернуть пустой результат из-за NULL! Одна из самых неприятных ловушек SQL — поведение NOT IN при наличии NULL. Запрос выглядит абсолютно корректно, но внезапно перестаёт возвращать строки. Таблицы:

users(id)
bans(user_id)

Допустим, нужно получить пользователей, которых нет в bans. Часто пишут так:

SELECT *
FROM users
WHERE id NOT IN (
    SELECT user_id
    FROM bans
);

Пока в bans.user_id нет NULL — всё работает нормально. Но представим данные:

bans
-------
1
2
NULL

Теперь запрос внезапно вернет:

0 rows

Хотя пользователи без бана есть. Почему так происходит — SQL сравнивает условие примерно как:

id <> 1
AND id <> 2
AND id <> NULL

Но:

id <> NULL

не даёт TRUE или FALSE. Результат: UNKNOWN. А в WHERE проходят только TRUE. Из-за этого всё условие целиком перестаёт выполняться. Это особенность трёхзначной логики SQL: TRUE, FALSE, UNKNOWN Любое сравнение с NULL даёт UNKNOWN:

NULL = 1
NULL <> 1
NULL = NULL

Поэтому NOT IN с NULL внутри подзапроса становится опасным. Безопасный вариант — NOT EXISTS:

SELECT *
FROM users u
WHERE NOT EXISTS (
    SELECT 1
    FROM bans b
    WHERE b.user_id = u.id
);

Почему EXISTS работает нормально: сравнение идёт построчно; NULL не ломает всю проверку; оптимизатор обычно хорошо превращает это в anti-join. Ещё вариант — явно убрать NULL:

SELECT *
FROM users
WHERE id NOT IN (
    SELECT user_id
    FROM bans
    WHERE user_id IS NOT NULL
);

Но на практике: NOT EXISTS обычно считается более безопасным и читаемым решением. Отдельный момент: NOT IN () и NOT EXISTS могут давать разные планы выполнения в зависимости от СУБД. Но логически для nullable данных: NOT EXISTS почти всегда предпочтительнее. Быстрая проверка проблемы:

SELECT COUNT(*)
FROM bans
WHERE user_id IS NULL;

Если такие строки есть — NOT IN уже потенциально опасен. 🔥 NOT IN и NULL плохо сочетаются. Если в подзапросе появляется хотя бы один NULL, условие может перестать возвращать строки вообще. Для таких проверок надёжнее использовать NOT EXISTS. ➡️ SQL Ready | #практика

Ты аналитик. Ты тащишь на себе дашборды, A/B-тесты и SQL в 10 вкладках. А при мыслях об автоматизации задач и усилении своих скиллов, осекаешься - повышение квалифкации стоит десятки тысяч. Больше 60% работодателей уже заложили бюджет на развитие команды в этом году. Просто большинство аналитиков никогда не просят. Потому что не знают, как. Мы собрали полный гайд: → 8 шагов от «хочу прокачаться» до «компания всё оплатила» → Готовые обоснования для руководителя → Скрипты ответов на возражения → Чек-лист перед разговором с HR Здесь - твоя грамотная заявка на корпоративный грант. 📄 Забирай методичку бесплатно → https://tglink.io/0516683a1ec128 Реклама. ООО "АЙТИ РЕЗЮМЕ". ИНН 4025460134. erid: 2W5zFHW9GuF

📂 Напоминалка по Data Engineering и аналитической архитектуре! Например, Data Warehouse хранит уже очищенные и структурированные данные для BI и отчетности, Data Lake позволяет складировать сырые данные любого типа и обрабатывать их по мере необходимости, а Data Mesh распределяет владение данными между бизнес-доменами и превращает данные в полноценные data products. На картинке — основные отличия: как хранятся данные, кто ими управляет, как происходит обработка и для каких задач лучше подходит каждый подход. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

BUFFERS: как увидеть цену запроса? Обычный EXPLAIN ANALYZE показывает время выполнения, но почти ничего не говорит о том, сколько данных было прочитано с диска и из памяти.

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...

Опция BUFFERS добавляет статистику по страницам памяти: shared hit — страницы найдены в PostgreSQL shared buffers. shared read — страницы пришлось загрузить в shared buffers; это может быть физический диск или OS page cache.

Buffers: shared hit=15000 read=2

Такой запрос почти полностью работает из памяти, что хорошо. А здесь видно узкое место: запрос массово читает диск, даже если по времени более менее.

Buffers: shared hit=10 read=15000

🔥 Два запроса с одинаковым execution time могут иметь абсолютно разную нагрузку на систему. ➡️ SQL Ready | #совет

👨👨👨👨👨👨👨👨👨👨 Каналы с Junior IT вакансиями и стажировками Подписывайся и забирай свой оффер 🤘 1. Стажировки и вакансии по России и миру 2. IT вакансии по СНГ 3. IT стажировки по СНГ 4. ИИ-ассистент для автооткликов 5. IT стажировки и волонтерства 6. IT стажировки в топовых компаниях мира 7. Удалённые IT вакансии и стажировки 8. Python вакансии и стажировки 9. БИГТЕХ вакансии и стажировки 10. Design вакансии и стажировки 11. QA вакансии и стажировки 12. Junior вакансии и стажировки 13. Frontend вакансии и вопросы собесов 14. Вакансии и стажировки для аналитиков 15. Вакансии в русских стартапах за границей 16. Вакансии и стажировки для DevOps 17. Вакансии, которых нет на ХХ.РУ

😍 SQL шпаргалка для начинающих — база по работе с бд! Удобный и понятный справочник, где разобраны основные SQL-запросы и конструкции: SELECT, WHERE, JOIN, INSERT, UPDATE и другие ключевые команды. Всё объясняется простым языком с примерами, чтобы быстро понять логику работы с данными и начать применять это в реальных задачах 📌 Оставляю ссылочку: ermita.one ➡️ SQL Ready | #ресурс

Генерация пропущенных дат в отчётах: почему LEFT JOIN не помогает! Классическая задача — построить отчёт по дням. Например, количество заказов по датам. И внезапно оказывается, что в выдаче нет некоторых дней. Таблица:

orders(id, created_at)

Плохой вариант:

SELECT
    DATE(created_at) AS day,
    COUNT(*) AS orders_count
FROM orders
GROUP BY DATE(created_at)
ORDER BY day;

Проблема: если в какой-то день не было заказов — строки просто не будет. В аналитике это почти всегда ошибка, потому что отсутствие строки не равно ноль значений. Попытка через LEFT JOIN сама по себе не помогает — без таблицы дат нечего достраивать. Правильный подход — сначала явно сгенерировать календарь, а потом присоединить данные. В PostgreSQL для этого есть generate_series:

WITH calendar AS (
    SELECT generate_series(
        DATE '2026-01-01',
        DATE '2026-01-10',
        INTERVAL '1 day'
    )::date AS day
)
SELECT
    c.day,
    COUNT(o.id) AS orders_count
FROM calendar c
LEFT JOIN orders o
  ON DATE(o.created_at) = c.day
GROUP BY c.day
ORDER BY c.day;

Теперь: каждый день присутствует; если заказов нет — COUNT(o.id) вернёт 0. Почему именно COUNT(o.id), а не COUNT(*): COUNT(*) посчитает строку календаря даже без совпадений — всегда ≥ 1; COUNT(o.id) считает только реальные заказы — корректный 0 при отсутствии данных. Ещё один важный момент — условие в JOIN: ON DATE(o.created_at) = c.day. Так писать удобно, но это ломает использование индекса по created_at. Лучше диапазон:

ON o.created_at >= c.day
AND o.created_at <  c.day + INTERVAL '1 day'

Это позволяет использовать индекс и ускоряет запрос на больших таблицах. Расширение задачи — накопительный итог по дням (используется тот же CTE calendar):

SELECT
    c.day,
    COUNT(o.id) AS orders_count,
    SUM(COUNT(o.id)) OVER (ORDER BY c.day) AS running_total
FROM calendar c
LEFT JOIN orders o
  ON o.created_at >= c.day
 AND o.created_at <  c.day + INTERVAL '1 day'
GROUP BY c.day
ORDER BY c.day;

Если нужно ограничение по периоду по данным, а не вручную:

WITH bounds AS (
    SELECT
        MIN(created_at)::date AS min_day,
        MAX(created_at)::date AS max_day
    FROM orders
),
calendar AS (
    SELECT generate_series(min_day, max_day, INTERVAL '1 day')::date AS day
    FROM bounds
)
SELECT ...

Календарь строится автоматически по данным. Если created_at — timestamptz, границы дня зависят от timezone. 🔥 Если в отчёте есть время — сначала формируйте ось времени, потом присоединяйте данные. Иначе вы работаете не с нулями, а с отсутствием строк, что даёт искажённую картину. ➡️ 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