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

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

• Преобразуем интервалы в точки начала и конца, чтобы работать с ними как с потоком событий; • Посчитаем текущую нагрузку через накопительную сумму по времени; • Найдём момент максимального количества одновременных событий — пик нагрузки системы.

Этот приём используется в мониторинге, аналитике, планировщиках и системах, где важно контролировать параллельную активность. ➡️ SQL Ready | #задача

🔥База платных курсов и книг по программированию на весь 2026 год!🔥 Канал новый, потому что слишком много людей ждут халявы. Тут всё, что обычно стоит тысячи: — Авторские курсы, которые не найти в открытом доступе — Самые свежие книги для старта — Всё, что нужно, чтобы за полгода вырасти от мидла до сеньора ➡️ Залетайте, пока есть доступ!

☕️ Годную статью нашёл на Хабре: «Как работает распределённый SQL в YDB: от запроса до выполнения»! В этой статье: • Показано, как в YDB обрабатывается SQL-запрос — от парсинга до распределённого исполнения по узлам; • Разбирается, как устроены планировщик, оптимизатор и механизмы шардинга при работе с большими данными; • Объясняется, как достигаются консистентность, отказоустойчивость и масштабируемость в распределённой базе.

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

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

Почему после JOIN внезапно растут агрегаты! Одна из самых неприятных ошибок в аналитическом SQL — когда запрос выглядит нормально, всё отрабатывает без ошибок, а цифры в итоге получаются больше, чем должны быть. Классическая ситуация. Есть таблицы:

    
        orders(id, customer_id, amount)
order_items(id, order_id, product_id, quantity)
{}
    

Допустим, хотим посчитать сумму заказов. На первый взгляд кажется, что такой запрос окей:

    
        SELECT SUM(o.amount) AS total_revenue
FROM orders o
JOIN order_items i
  ON i.order_id = o.id;
{}
    

Но тут и начинается подвох. Если у одного заказа 3 позиции в order_items, то строка из orders после JOIN повторится 3 раза. И o.amount тоже попадёт в расчёт 3 раза. В итоге сумма завышается. Это как раз тот самый fan-out: одна строка размножается после JOIN. Быстрая проверка, есть ли проблема:

    
        SELECT
    COUNT(*)             AS rows_after_join,
    COUNT(DISTINCT o.id) AS unique_orders
FROM orders o
JOIN order_items i
  ON i.order_id = o.id;
{}
    

Если строк после JOIN стало больше, чем уникальных заказов, значит у вас fan-out по уровню orders. Что делать правильно — зависит от задачи. Если вам нужна просто сумма по заказам, то JOIN вообще не нужен:

    
        SELECT SUM(amount)
FROM orders;
{}
    

Если JOIN нужен только для фильтрации, например по конкретному товару, безопаснее использовать EXISTS:

    
        SELECT SUM(o.amount)
FROM orders o
WHERE EXISTS (
    SELECT 1
    FROM order_items i
    WHERE i.order_id = o.id
      AND i.product_id = 10
);
{}
    

Почему это хорошо: гранулярность orders не ломается. Один заказ остаётся одной строкой. Ещё нормальный вариант — сначала убрать дубли на стороне order_items:

    
        SELECT SUM(o.amount)
FROM orders o
JOIN (
    SELECT DISTINCT order_id
    FROM order_items
    WHERE product_id = 10
) i ON i.order_id = o.id;
{}
    

Тут мы заранее приводим данные к уровню одна строка = один заказ, и только потом джойним. А если задача вообще на уровне позиций, например нужно посчитать общее количество товаров, тогда считать надо уже по order_items:

    
        SELECT SUM(i.quantity)
FROM order_items i;
{}
    

То есть важный момент очень простой: агрегировать нужно на том уровне, где реально живёт ваша метрика. Отдельно про популярный костыль:

    
        SELECT SUM(DISTINCT o.amount)
FROM orders o
JOIN order_items i
  ON i.order_id = o.id;
{}
    

С виду кажется, что DISTINCT сейчас всё починит, на деле — нет. Почему это плохая идея: если у двух разных заказов одинаковый amount, один из них просто схлопнется; запрос начинает давать вроде бы правдоподобный, но неверный результат. Ещё неприятнее, когда JOIN не один, а цепочка: orders — order_items — products — categories Практический способ быстро это поймать — смотреть количество строк после каждого шага:

    
        SELECT COUNT(*) FROM orders;

SELECT COUNT(*)
FROM orders
JOIN order_items ON order_items.order_id = orders.id;

SELECT COUNT(*)
FROM orders
JOIN order_items ON order_items.order_id = orders.id
JOIN products ON products.id = order_items.product_id;
{}
    

Так обычно сразу видно, на каком JOIN начинаются лишние строки. 🔥 Итог простой: перед тем как писать JOIN, всегда держите в голове гранулярность данных. Что у вас является одной строкой: заказ, позиция заказа, клиент? Сначала определяете уровень данных — потом джойните и агрегируете. ➡️ SQL Ready | #практика

📚 Physics.Math.Code — крупнейшее русскоязычное сообщество с лучшим контентом для физиков, математиков и разработчиков. 🎥 Учебные фильмы — фильмы по физике, математике, программированию, технологиях, химии, биологии. Самые интересные видео для развития. 👾 Эпсилон — канал с книгами по информационной безопасности, IT технологиям, робототехнике и достижениям Computer Science. 💡 Репетитор IT men — блог с заметками преподавателя по физике, математике, IT, железе. Разборы интересных задач, рассуждения о науке, образовании и методах обучения. ⚙️ Техника .TECH — эстетика технологий различных времен. 🧠 Псевдоинтеллектуал — канал в духе околонаучного хаоса: шутки, философия, наука, споры, поводы для рефлексии. ✏️ Physics.Math.Code — чат по серьезным вопросам по физике, математике, программированию и IT в целом. 📝 Техночат — обсуждаем технические книги и посты канала Physics.Math.Code

📂 Напоминалка по блокировкам и транзакциям в SQL! Optimistic locking позволяет работать без блокировок — конфликт проверяется при записи (например, через version или updated_at). Pessimistic locking наоборот сразу ставит блокировку (SELECT ... FOR UPDATE) и заставляет другие транзакции ждать. На картинке — как два подхода ведут себя при одновременном обновлении одной строки: в одном случае получаем conflict, в другом — очередь. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Как вернуть строки в том же порядке, в котором пришли id? Когда из приложения прилетает список id, обычный WHERE id = ANY(...) находит нужные строки, но порядок входного массива не сохраняет:

    
        SELECT *
FROM users
WHERE id = ANY(ARRAY[42, 7, 99]);{}
    

Такой запрос вернёт правильный набор строк, но порядок будет таким, как решит планировщик, а не таким, как пришёл список. WITH ORDINALITY добавляет каждой строке её позицию во входном наборе:

    
        unnest(ARRAY[42, 7, 99]) WITH ORDINALITY{}
    

Дальше это уже обычная таблица, которую можно джойнить, фильтровать и сортировать:

    
        ORDER BY x.ord{}
    

В итоге база сама возвращает строки в нужном порядке, без CASE, без ручной сортировки в коде и без лишнего постобработчика. 🔥 WITH ORDINALITY — это простой способ сохранить порядок входных данных в SQL, он хорошо заходит в API и массовые выборки. ➡️ SQL Ready | #совет

Ищут 10 человек, чтобы собирали чат-ботов по шаблону, как пазлы. ЗП: от 5-9000₽ за вечер. Занятость: 3-4 часа в день. Опыт: не нужен. Как мы работаем: 1. Ты проходишь обучение пару недель; 2. Берёшь реальный проект из моей базы; 3. Собираешь бота по проверенной формуле; 4. Наставник контролирует процесс; 5. Получаешь деньги и закрепляешь клиента. Весь процесс занимает до 2х недель с нуля до первых денег на твою карту. Даниил из Балашихи был военнослужащим — с июля 2024 года начал создавать чат-ботов для бизнеса и уже заработал 4 млн. рублей. А главное теперь у него больше свободного времени на семью, друзей и развлечения. Да, ты не первый. 206 человек уже ведут постоянных клиентов по моей формуле. Ведь сайт со статистикой Wordstat показывает 10 786 запросов за месяц в поисковике от бизнеса на эту услугу. Заказов валом. Срочно нужны твои руки и голова. Чтобы быстро разобраться во всех нюансах — запускай бота Там пошаговый план как стартануть и гайд по клиентам. 8 мест ещё свободно

🧐 SQL Syntax Cheat Sheet — справочник по SQL-синтаксису! Универсальная шпаргалка по SQL, где собраны все основные конструкции языка. Всё структурировано по разделам, поэтому можно быстро найти нужный синтаксис. Формат максимально практичный: команда, пример, объяснение, что позволяет не просто смотреть, а сразу понимать, как что применяется в запросах.

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

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