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

Нужно найти, где бронирования, подписки или сессии пересекаются по времени? Два интервала пересекаются, если начало одного раньше конца другого, и наоборот:

a.start_at < b.end_at
AND b.start_at < a.end_at

Это условие покрывает все случаи перекрытий, даже частичных и вложенных. Теперь объедини данные сами с собой:

SELECT a.id, b.id
FROM bookings a
JOIN bookings b
  ON a.id < b.id
 AND a.start_at < b.end_at
 AND b.start_at < a.end_at;

a.id < b.id, чтобы не получить пары в обе стороны. Хочешь анализировать бронирования по ресурсу? Добавь фильтр:

AND a.room_id = b.room_id

🔥 Теперь видно, какие заявки реально конфликтуют по времени. ➡️ SQL Ready | #совет

🖥 SQL-генерация полного набора домино! Сегодня соберём 28 уникальных костяшек домино — только силами SQL. Без циклов и хранимых процедур, используя лишь CROSS JOIN и простое условие. В этом посте:

• Генерируем все пары чисел от 0 до 6; • Фильтруем зеркальные комбинации; • Получаем финальный набор костяшек в правильном порядке.

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

🖥 SQLHUB – с помощью понятных картинок и коротких видео авторы объясняют сложные концепции и учат профессиональному подходу в работе с БД. 💼 Data Jobs - нужна работа? Здесь отборные вакансии и фриланс проекты по работе с базами данных, sql и не только. 🧠 Machine learning - показываем на примере как использовать AI, который может генерировать готовые базы данных, код, разбираем все что нужно знать в области ИИ. 🖥 SQL задачи - решайте отборные задачи и качайте скилы. 📚 Библиотека - мы создали канал с книгами по SQL и залили туда наверное самую большую подборку книг по SQL. Около 200 книг бесплатно. 🔝 А здесь мы собрали целую кладезь полезных SQL ресурсов для прокачки

Оптимистическая блокировка: обновляем данные без конфликтов! Когда несколько пользователей редактируют одну запись, можно избежать конфликтов с помощью оптимистической блокировки — без явного FOR UPDATE. Создаём таблицу с версией записи:

CREATE TABLE products (
    id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT,
    price DECIMAL(10,2),
    version INT DEFAULT 1 NOT NULL
);

Выбираем запись для редактирования:

SELECT id, name, price, version
FROM products
WHERE id = 1;

Обновляем с проверкой версии:

UPDATE products
SET price = 199.99,
    version = version + 1
WHERE id = 1
  AND version = 1;

Если другой пользователь уже изменил эту строку, UPDATE не затронет ни одной записи — значит, версия изменилась, и данные устарели. Приложение должно проверить, что rows_affected = 1, и при необходимости повторить попытку или показать сообщение об ошибке. Проверяем результат:

SELECT * FROM products WHERE id = 1;

🔥 Такой подход предотвращает «потерю обновлений» без длительных блокировок чтения и подходит для большинства современных СУБД. ➡️ SQL Ready | #практика

🖥 Контроль целостности данных! С помощью оконных функций SQL можно находить разрывы во временных рядах, пропущенные интервалы и повторяющиеся записи. Сегодня в гайде:

• Выявляем пропущенные минуты и события; • Находим дубликаты временных меток; • Контролируем качество потоков и ETL прямо в запросах.

В продакшн-аналитике важно не только считать, но и замечать, где данные пропали или задублировались. ➡️ SQL Ready | #гайд

⚡️⚡️⚡️ Мы собрали 7 самых сильных IT-каналов 2025 года. Никакой воды — только боевой стек: ⌨️ Pro Python • IT – от скриптов до нейросетей ⚙ Pro DevOps | Linux – автоматизация, облака, администрирование 👣 Pro Go – высоконагруженные системы и микросервисы 🖥 Pro JavaScript & TypeScript – полный стек ⚙ Pro Backend – архитектура, базы данных, API 🖥 Pro Frontend – современные фреймворки и инструменты ⌨️ Pro Java – промышленная разработка и фреймворки Подписывайся сейчас, смотреть будешь потом! 👍

🖥 Работа с JSON в PostgreSQL! В этой шпаргалке собраны основные приёмы работы с JSON и JSONB в PostgreSQL: доступ к элементам, извлечение вложенных данных, обновление значений, создание объектов, раскрытие массивов, форматирование и проверка вхождения. Эти инструменты позволяют удобно хранить и обрабатывать структурированные данные прямо в базе. ➡️ SQL Ready | #шпора

Telegram опубликовал список 8 самых быстрорастущих каналов для программистов: Only Python — Подборки приёмов и фич, о которых не рассказывают в курсах. Only Tech — Главные тренды и инсайды из мира технологий, маркетинга и интернет-культуры. Only Hack — Реальные кейсы кибератак, инструменты и методы защиты, которые используют хакеры. Only GitHub — Репозитории, которые решают реальные задачи. Скрипты, фреймворки и готовые решения Only IT — Без мнений и слухов — только факты и важные IT-события. Only Apple — Новые апдейты, утечки и фишки, которые Apple ещё не показала. Only GPT — Промпты, хаки и свежие инструменты, о которых молчат даже AI-каналы. Only Memes — Если ты когда-нибудь деплоил в пятницу вечером — ты поймешь Подписывайтесь и прокачивайте свои скиллы.

Хочешь узнать, когда именно заказ сменил статус? Используй LAG(), она возвращает значение из предыдущей строки в рамках группы:

LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at)

Сравни текущее значение с предыдущим:

status <> LAG(status) OVER (...)

Получается булево поле — true, когда статус поменялся. Хочешь вывести только моменты изменения, просто оберни в подзапрос:

SELECT *
FROM (
  SELECT order_id, status, updated_at,
         status <> LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at) AS changed
  FROM order_status_log
) t
WHERE changed;

🔥 Это основа для аудита изменений и аналитики событийных логов. ➡️ SQL Ready | #совет

🖥 Корреляция: как связаны просмотры и продажи! SQL умеет не только суммировать и фильтровать данные, он способен показывать насколько сильно одно влияет на другое. В этом посте:

• Находим средние значения метрик; • Считаем ковариацию и дисперсии; • Собираем финальную формулу корреляции прямо в запросе.

Это помогает быстро проверять гипотезы, оценивать результаты и находить зависимости. ➡️ SQL Ready | #задача

👩‍💻 В сеть вывалилась гигантская куча курсов и книг от топовых IT‑школ Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё! • 1612 ГБ — DevOps • 1402 ГБ — Python • 1300 ГБ — C, C++ • 1815 ГБ — Frontend • 1515 ГБ — Backend • 898 ГБ — ИБ, Хакинг • 996 ГБ — Kotlin, Swift • 212 ГБ — JavaScript • 315 ГБ — Flutter • 820 ГБ — Go, PHP • 419 ГБ — Java, Rust • 648 ГБ — GameDev • 517 ГБ — Windows, Linux • 998 ГБ — Дизайн (UX/UI) • 617 ГБ — Нейросети (ML/RL) • 546 ГБ — БД (SQL & NoSQL) • 687 ГБ — Аналитика данных • 115 ГБ — QA-тестирование Подписывайся и не плати за то, что можно получить бесплатно

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

SELECT
    category_id,
    LISTAGG(product_name, ', ') WITHIN GROUP (ORDER BY total_sales DESC) AS top_products
FROM product_sales
GROUP BY category_id;

В отличие от ARRAY_AGG(product_name ORDER BY ...), синтаксис WITHIN GROUP используется для ordered-set функций, а не для любых агрегатов. Пример вычисления порогового значения 90% по сумме заказов по регионам:

SELECT
    region_id,
    PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY total_amount) AS p90_sales
FROM orders
GROUP BY region_id;

PERCENTILE_CONT() и PERCENTILE_DISC() позволяют вычислять медиану или любое процентное значение без оконных функций. Медиана чека по каждому магазину:

SELECT
    store_id,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY total_amount) AS median_check
FROM orders
GROUP BY store_id;

Такой подход может быть проще и эффективнее, чем использование NTILE() или RANK() в оконных выражениях. 🔥 Используйте WITHIN GROUP, когда важен порядок в агрегатах. ➡️ SQL Ready | #практика

🖥 Временные таблицы и переменные в SQL Server! В этой шпаргалке собраны основные приёмы работы с временными данными в SQL Server: создание, заполнение, очистка и удаление временных таблиц, а также использование табличных переменных. Эти методы помогают выполнять промежуточные расчёты, строить отчёты и оптимизировать сложные запросы без изменения основной схемы базы. ➡️ SQL Ready | #шпора

🖥 Пишем мини-чат-бота! Сегодня создаём простого бота, который “понимает” текст запроса и отвечает на сообщения пользователя. В этом посте:

• Храним шаблоны фраз и ответы в таблице responses; • Используем ILIKE, чтобы находить ключевые слова в сообщении; • Возвращаем лучший ответ по приоритету совпадений.

Приём показывает, что SQL способен работать не только с числами, но и с текстом, превращаясь в мини-экспертную систему. ➡️ SQL Ready | #задача

Транзакция — не просто “begin и commit”, а ещё и способ управлять атомарностью и блокировками! Начинаешь с BEGIN — всё, что дальше, идёт как единое целое:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Если что-то падает, делай rollback, и база возвращается к исходному состоянию. Не забывай: каждая открытая транзакция держит блокировки. Чем дольше она живёт, тем выше шанс конфликтов. Контролируй уровень изоляции - баланс между скоростью и безопасностью:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

🔥 Производительность БД начинается с правильного управления транзакциями и блокировками. ➡️ SQL Ready | #совет

USING — способ объединять таблицы в SQL! Когда таблицы имеют одинаковые ключи, USING помогает сократить код и избежать дублирования столбцов. Объединим заказы и клиентов по общему полю:

SELECT *
FROM orders
JOIN customers USING (customer_id);

То же самое через ON выглядело бы чуть длиннее и менее лаконично:

SELECT *
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id;

С USING SQL сам убирает дубликаты полей, оставляя одно customer_id в результирующем наборе. Можно соединять и по нескольким ключам:

SELECT *
FROM orders
JOIN shipments USING (order_id, customer_id);

Пример из аналитики: посчитаем сумму заказов по каждому клиенту:

SELECT customer_id,
       c.customer_name,
       SUM(o.amount) AS total_amount
FROM customers c
JOIN orders o USING (customer_id)
GROUP BY customer_id, c.customer_name
HAVING SUM(o.amount) > 1000
ORDER BY total_amount DESC;

🔥 Используйте USING, когда имена ключей совпадают — это приём, который улучшает читаемость и уменьшает вероятность ошибок. ➡️ SQL Ready | #практика

⚡️ Запускаем крупный розыгрыш призов, где можно выиграть iPhone 17, игровые наушники, клавиатуру и мышь! Без лишних слов, условия: 1. Подписка на: — бизнестрендс — Технотренды — Блумберг 2. Нажать кнопку «Участвовать» снизу Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!

❤️ CodeAbbey — тренажёр алгоритмического мышления! Сайт с огромной коллекцией задач по программированию, от самых простых до тех, что реально заставят подумать. Учиться можно на абсолютно любом языке. Отличный способ подтянуть логику, научиться писать аккуратный код и подготовиться к собесам. 📌 Оставляю ссылочку: codeabbey.com ➡️ SQL Ready | #ресурс