В этой задаче напишем SQL-запрос, который поможет выявить, как часто пользователи отменяют заказы за последние 90 дней — и покажем это в разрезе дней и недель.
Что делаем:
• Считаем общее количество заказов и отдельно — отменённые (status = 'canceled').
• Используем CTE для упрощения структуры запроса и фильтрацию по последним 90 дням.
• Группируем по неделям с помощью DATE_TRUNC, чтобы отследить тренды.
Если процент отмен выше 7 % — это сигнал для бизнеса: стоит проверить, не возникают ли сбои в доставке, оплате или интерфейсе.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤6👍4
Имеем три таблицы: ps — фотосессии, ps_data — данные фотосессий и photo — фотографии. Таблицы ps_data и photo связаны с таблицей ps psid.
Необходимо вернуть активные фотосессии и принадлежащие им активные фотографии фотографа под номером 7.
В этой задаче:
• CTE — разбиваем сложный запрос с дабл джоинами на несколько простых.
• WHERE — для фильтрации активный фотосессий нужного фотографа и активных фотографий.
• JOIN — для связи фотографий и фотосессий.
🔥 — если узнал что-то новое
🤝 — если знал решение
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍7❤6🤝1
ON CONFLICT DO NOTHING — апсерты без ошибок!
Когда вы вставляете данные в таблицу с уникальными ограничениями, может прилететь ошибка: дубликат ключа нарушает уникальность. Особенно обидно, если часть данных уже вставлена, а часть — нет.
Чтобы обойти это — используем
Допустим, у нас есть таблица с пользователями, где email должен быть уникальным:
Попробуем вставить сразу несколько строк, включая дубликат:
Результат будет неудачным — Postgres выдаст ошибку и отменит всю операцию. Однако с
🔥 Теперь база данных вставит только уникальные строки, а повторяющиеся — просто пропустит без лишнего шума.
➡️ SQL Ready | #практика
Когда вы вставляете данные в таблицу с уникальными ограничениями, может прилететь ошибка: дубликат ключа нарушает уникальность. Особенно обидно, если часть данных уже вставлена, а часть — нет.
Чтобы обойти это — используем
ON CONFLICT DO NOTHING. Он просто пропустит строки, которые уже есть.Допустим, у нас есть таблица с пользователями, где email должен быть уникальным:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email TEXT UNIQUE
);
Попробуем вставить сразу несколько строк, включая дубликат:
INSERT INTO users (email)
VALUES ('[email protected]'),
('[email protected]'),
('[email protected]'); -- дубликат!
Результат будет неудачным — Postgres выдаст ошибку и отменит всю операцию. Однако с
ON CONFLICT всё работает иначе:INSERT INTO users (email)
VALUES ('[email protected]'),
('[email protected]'),
('[email protected]')
ON CONFLICT DO NOTHING;
🔥 Теперь база данных вставит только уникальные строки, а повторяющиеся — просто пропустит без лишнего шума.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍8🔥6
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14🔥8👍4🤝3
В этой задаче напишем SQL-запрос, который поможет построить отчёт по неоплаченным счетам и оценить просроченную дебиторскую задолженность.
Что делаем:
• Распределяем счета по корзинам: 0-30, 31-60, 61-90, 90+ дней просрочки.
• Считаем сумму, количество и долю задолженности по каждой корзине.
• Строим топ-5 крупнейших должников с просрочкой более 60 дней.
Такой отчёт позволяет увидеть, где «зависли» деньги, и помогает сфокусироваться на проблемных клиентах
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤5👍5