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

🖥 Разбираемся с LATERAL JOIN — подзапрос как функция! С помощью LATERAL можно использовать значения из текущей строки в подзапросе — как будто передаёшь параметры в функцию. Что важно знать:

• LATERAL делает подзапросы внутри JOIN «осведомлёнными» о текущей строке. • Удобно, когда нужно посчитать агрегаты или достать top-N из связанных таблиц. • Отлично работает с jsonb, позволяя обойтись без оконных функций.

Инструмент, с которым сложные запросы станут в разы проще. ➡ SQL Ready | #гайд

🖥 Aging-отчёт по просроченным счетам! В этой задаче напишем SQL-запрос, который поможет построить отчёт по неоплаченным счетам и оценить просроченную дебиторскую задолженность. Что делаем:

• Распределяем счета по корзинам: 0-30, 31-60, 61-90, 90+ дней просрочки. • Считаем сумму, количество и долю задолженности по каждой корзине. • Строим топ-5 крупнейших должников с просрочкой более 60 дней.

Такой отчёт позволяет увидеть, где «зависли» деньги, и помогает сфокусироваться на проблемных клиентах ➡ SQL Ready | #задача

🖥 Профилирование производительности — способ найти и устранить узкие места в базе данных! Позволяет понять, какие запросы и функции съедают ресурсы, где тормозит система и как это исправить. Отличный инструмент для ускорения и оптимизации работы с данными. ➡️ SQL Ready | #шпора

ON CONFLICT DO NOTHING — апсерты без ошибок! Когда вы вставляете данные в таблицу с уникальными ограничениями, может прилететь ошибка: дубликат ключа нарушает уникальность. Особенно обидно, если часть данных уже вставлена, а часть — нет. Чтобы обойти это — используем ON CONFLICT DO NOTHING. Он просто пропустит строки, которые уже есть. Допустим, у нас есть таблица с пользователями, где email должен быть уникальным:

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email TEXT UNIQUE
);

Попробуем вставить сразу несколько строк, включая дубликат:

INSERT INTO users (email)
VALUES ('alice@example.com'),
       ('bob@example.com'),
       ('alice@example.com');  -- дубликат!

Результат будет неудачным — Postgres выдаст ошибку и отменит всю операцию. Однако с ON CONFLICT всё работает иначе:

INSERT INTO users (email)
VALUES ('alice@example.com'),
       ('bob@example.com'),
       ('alice@example.com')
ON CONFLICT DO NOTHING;

🔥 Теперь база данных вставит только уникальные строки, а повторяющиеся — просто пропустит без лишнего шума. ➡️ SQL Ready | #практика

🖥 Ищем активные фотосессии и фотографии фотографа №7! Имеем три таблицы: ps — фотосессии, ps_data — данные фотосессий и photo — фотографии. Таблицы ps_data и photo связаны с таблицей ps psid. Необходимо вернуть активные фотосессии и принадлежащие им активные фотографии фотографа под номером 7. В этой задаче:

• CTE — разбиваем сложный запрос с дабл джоинами на несколько простых. • WHERE — для фильтрации активный фотосессий нужного фотографа и активных фотографий. • JOIN — для связи фотографий и фотосессий.

🔥 — если узнал что-то новое 🤝 — если знал решение ➡ SQL Ready | #задача

🖥 Анализ отменённых заказов! (cancel rate) В этой задаче напишем SQL-запрос, который поможет выявить, как часто пользователи отменяют заказы за последние 90 дней — и покажем это в разрезе дней и недель. Что делаем:

• Считаем общее количество заказов и отдельно — отменённые (status = 'canceled'). • Используем CTE для упрощения структуры запроса и фильтрацию по последним 90 дням. • Группируем по неделям с помощью DATE_TRUNC, чтобы отследить тренды.

Если процент отмен выше 7 % — это сигнал для бизнеса: стоит проверить, не возникают ли сбои в доставке, оплате или интерфейсе. ➡ SQL Ready | #задача

❗️ Канал для тех, кто хочет хочет развиваться в кибербезе Project Omega — закрытая лаборатория белого хакера. Криптография на практике и разборы популярных инструментов защиты. 🔤Никаких заявок, канал открыт!

😎 W3Resource — онлайн-площадка, предназначенная для прокачки навыков работы с базами данных! На сайте собраны задания, распределённые по темам — от простых выборок до сложных подзапросов и агрегирования. Каждое упражнение снабжено детальным разбором и готовым решением 📌 Оставляю ссылочку: w3resource.com ➡️ SQL Ready | #ресурс

PARTITION PRUNING — читаем только нужные данные! Когда таблица разрастается до сотен миллионов строк, даже простые запросы начинают тормозить. Но часто нам нужен только один месяц — зачем читать всё? Чтобы ускорить выборку, разобьём таблицу на разделы по дате с помощью range partitioning:

CREATE TABLE sales (
  sale_date DATE,
  amount NUMERIC
) PARTITION BY RANGE (sale_date);

Теперь создадим конкретные партиции — каждая отвечает за свой месяц:

CREATE TABLE sales_2024_01 PARTITION OF sales
  FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE sales_2024_02 PARTITION OF sales
  FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

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

SELECT SUM(amount)
FROM sales
WHERE sale_date BETWEEN '2024-01-01' AND '2024-01-31';

Добавим EXPLAIN ANALYZE, чтобы увидеть, как именно Postgres выполняет запрос:

EXPLAIN ANALYZE
SELECT SUM(amount)
FROM sales
WHERE sale_date BETWEEN '2024-01-01' AND '2024-01-31';

🔥 Важно: pruning работает только, если условие по дате написано явно — без функций, кастов и переменных. ➡️ SQL Ready | #практика

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

☕️ Наткнулся на любопытную статью — автор написал собственный in-memory движок для MariaDB. В этой статье: • Пошаговая сборка MariaDB из исходников и первые «твики» результатов • Реализация минимального движка MEMEM с поддержкой CREATE/INSERT/SELECT • Отличие API движков хранения MariaDB от Postgres

🔊 Подробное руководство лежит на Habr!

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

🖥 Integrity constraints — фундамент корректных данных! Они защищают таблицы от мусора, дублирования и логических ошибок. Используй ограничения, чтобы база вела себя предсказуемо и честно. ➡️ SQL Ready | #шпора

Работать и не уставать, достигать цели, но делать это в кайф - реально! Как научиться делать дела и не выгорать? Психолог взрослого человека — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам. ▪️ Как научиться отвлекаться от работы и отдыхать? ▪️ Как совместить кучу рабочих задач и время с семьей? ▪️ Как справиться с прокрастинацией? ▪️ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит? Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни! 👨🏻‍💻 Псс. Заходите в закреп канала - там много полезного, и даже бесплатный мини-курс по выходу из апатии.

🖥 Осваиваем DISTINCT ON в PostgreSQL — быстрый способ выбрать первую строку из группы! Подходит для задач вроде «последний заказ клиента» или «первая операция по счёту». Работает компактно и быстрее оконных функций, если нужен один результат на группу. Что важно знать:

• Используется с ORDER BY — сначала поле из DISTINCT ON, затем сортировка внутри групп. • Без ORDER BY результат непредсказуем — зависит от физического порядка строк. • Альтернатива ROW_NUMBER() — тот же результат, но без подзапросов и лишнего кода.

DISTINCT ON — мощный инструмент в арсенале PostgreSQL, когда важна лаконичность и производительность. ➡ SQL Ready | #гайд

☕️ Сайт SQL Teaching — это простой и наглядный способ выучить SQL. Интерактивный сайт, где вы учитесь писать SQL-запросы в игровой форме. Всё происходит прямо в браузере: пишете запрос — сразу видите результат. 📌 Оставляю ссылочку: sqlteaching.com ➡️ SQL Ready | #ресурс

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

🐍💩👩‍💻👩‍💻🧑‍💻🧑‍💻🐧👩‍💻🧑‍💻👩‍💻👩‍💻 В сети начали массово сливать курсы и книги известных онлайн школ по айти Вот отсортированная база с тонной материала (постепенно пополняется): (363 видео, 87 книги) — Python (415 видео, 68 книги) — Frontend (143 видео, 33 книги) — ИБ/Хакинг (352 видео, 89 книги) — С/С++/C# (343 видео, 87 книги) — Java/QA (176 видео, 32 книги) — Git/Linux (174 видео, 91 книги) — DevOps (167 видео, 53 книги) — PHP/1С (227 видео, 83 книги) — SQL/БД (114 видео, 77 книги) — Сисадмин (107 видео, 43 книги) — BA/SA (181 видео, 32 книги) — Go/Rust (167 видео, 43 книги) — Kotlin/Swift (112 видео, 24 книги) — Flutter (137 видео, 93 книги) — DS/ML (113 видео, 82 книги) — GameDev (183 видео, 37 книги) — Дизайн (136 видео, 33 книги) — PM/HR Скачивать ничего не нужно — все выложили в Telegram

WINDOW FUNCTIONS — сравниваем строки без джойнов! Когда нужно показать, как изменилась цена по сравнению со вчерашним днём — часто пишут JOIN таблицы самой с собой. Но это сложно, медленно и плохо масштабируется при работе с большими таблицами. Вместо этого используем оконную функцию LAG() — она возвращает значение из предыдущей строки:

SELECT
  date,
  price AS today,
  LAG(price) OVER (
    PARTITION BY product_id
    ORDER BY date
  ) AS yesterday
FROM prices
WHERE product_id = 42;

Один проход по таблице, без соединений. План часто использует Index Only Scan, особенно при хороших индексах. Это делает запросы заметно быстрее и эффективнее. Нужен топ-3 товаров по продажам в каждой категории? Используем ROW_NUMBER():

SELECT *
FROM (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY category
      ORDER BY sales DESC
    ) AS rn
  FROM products
) AS ranked
WHERE rn <= 3;

🔥 Не забывайте ORDER BY внутри окна — он определяет порядок, по которому сравниваются строки. Без него результаты могут быть непредсказуемыми. ➡️ SQL Ready | #практика