
🌸 Майская распродажа
Скидки до 70% в каталоге + дополнительно 3,5% по промокоду 75D80F4B
В каталог
Купить рекламу в этом канале
Формат:
keyboard_arrow_down
- 1/24
- 2/48
- 3/72
- Нативный
- 7 дней
- Репост
1 час в топе / 24 часа в ленте
Количество:
keyboard_arrow_down
- 1
- 2
- 3
- 4
- 5
- 8
- 10
- 15
Стоимость публикации:
local_activity
10 069.92₽10 069.92₽local_mall
0.0%
Осталось по этой цене:0
Последние посты канала
imageИзображение не доступно для предпросмотра
🐘 Slonik — проверенный клиент PostgreSQL для Node.js с строгой типизацией и детальным логированием. Этот инструмент решает проблему безопасности и предсказуемости работы с SQL-запросами: вместо ручного формирования запросов проект заставляет использовать литералы с автоматическим экранированием параметров.
Интересна встроенная интеграция с Zod для валидации результатов запросов, она предотвращает ошибки при изменении схемы БД без обновления кода. Также Slonik умеет логировать стектрейсы вызовов запросов и перезапускать упавшие транзакции.
🤖 GitHub
@sqlhub
Интересна встроенная интеграция с Zod для валидации результатов запросов, она предотвращает ошибки при изменении схемы БД без обновления кода. Также Slonik умеет логировать стектрейсы вызовов запросов и перезапускать упавшие транзакции.
🤖 GitHub
@sqlhub
1300
17:03
15.05.2025
imageИзображение не доступно для предпросмотра
Изучите секреты самых популярных open source key-value СУБД – Redis и Valkey
В высоко-нагруженных сервисах Redis — не просто кэш, а важная подсистема, на которой строится значимая часть бизнес-логики. От его стабильности, масштабируемости и отказоустойчивости зависит производительность всего сервиса. Valkey - это современный производительный форк Redis с открытым исходным кодом, поддерживаемый сообществом и рядом крупных компаний. Valkey набирает популярность, поддержан крупными облачными провайдерами, и вполне возможно потеснит или вовсе заменит Redis со временем. Наш курс — для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроен Redis и Valkey.
🌐 В программе курса:
🤩 Как эффективно использовать базовые и продвинутые структуры данных: HyperLogLog, Bitmaps и Bisields, Streams, Geospatial-индексы, Bloom Filters
🤩 Как проектировать in-memory системы, которые не разваливаются под нагрузкой, что влияет на отказоустойчивость и как её добиться
🤩 Как работает репликация и кластеризация на практике (режимы Sentinel и Cluster)
🤩 Как встроить Redis/Valkey в реальный прод с учётом безопасности, интеграций и современных практик мониторинга.
🥸 Кто мы: R&D-центр Devhands. Автор курса — Константин Ратвин — преподаватель МФТИ на кафедре БИТ (совместно со СберТех), эксперт по распределённым системам и банковским ИТ, автор курсов по СУБД и инфраструктуре, спикер HighLoad++ и PGConf.
🗓 Старт курса: 9 июня, 6 недель обучения.
Изучить программу и записаться можно здесь.
Ждем вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqwXctGc
В высоко-нагруженных сервисах Redis — не просто кэш, а важная подсистема, на которой строится значимая часть бизнес-логики. От его стабильности, масштабируемости и отказоустойчивости зависит производительность всего сервиса. Valkey - это современный производительный форк Redis с открытым исходным кодом, поддерживаемый сообществом и рядом крупных компаний. Valkey набирает популярность, поддержан крупными облачными провайдерами, и вполне возможно потеснит или вовсе заменит Redis со временем. Наш курс — для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроен Redis и Valkey.
Изучить программу и записаться можно здесь.
Ждем вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqwXctGc
1400
15:02
15.05.2025
imageИзображение не доступно для предпросмотра
🦦 Walrus — удобная обёртка над Redis для Python-разработчиков. Этот проект расширяет стандартный клиент redis-py, добавляя к нему набор полезных абстракций для работы с Redis.
Вместо того чтобы заставлять изучать новый API, Walrus предлагает привычный интерфейс с дополнительными возможностями. При этом проект остаётся лёгковесным и сохраняет совместимость с альтернативными Redis-подобными базами вроде rlite.
🤖 GitHub
@sqlhub
Вместо того чтобы заставлять изучать новый API, Walrus предлагает привычный интерфейс с дополнительными возможностями. При этом проект остаётся лёгковесным и сохраняет совместимость с альтернативными Redis-подобными базами вроде rlite.
🤖 GitHub
@sqlhub
1800
11:01
15.05.2025
imageИзображение не доступно для предпросмотра
Если вы размышляете, как усилить своё резюме, наш совет — освойте SQL. Это язык, который помогает извлекать ценную информацию из массивов данных.
Познакомиться с инструментом можно на бесплатном курсе «Введение в SQL и работу с базой данных». За 5 занятий вы научитесь создавать, редактировать и обновлять базы данных, сделаете свои первые запросы и отчёты.
Курс будет полезен даже тем, кто пока не собирается становиться аналитиком. Научитесь применять SQL в своих задачах — с ним вы сможете больше – https://netolo.gy
Реклама. ООО "Нетология". ИНН 7726464125 Erid: 2VSb5y1d224
Познакомиться с инструментом можно на бесплатном курсе «Введение в SQL и работу с базой данных». За 5 занятий вы научитесь создавать, редактировать и обновлять базы данных, сделаете свои первые запросы и отчёты.
Курс будет полезен даже тем, кто пока не собирается становиться аналитиком. Научитесь применять SQL в своих задачах — с ним вы сможете больше – https://netolo.gy
Реклама. ООО "Нетология". ИНН 7726464125 Erid: 2VSb5y1d224
2000
09:02
15.05.2025
🧠 SQL-задача с подвохом: “Самый активный — или самый невидимый?”
📘 Условие
У тебя есть две таблицы:
Вопрос:
Выведи всех пользователей, у которых нет ни одного поста,
а также пользователя, у которого больше всего постов.
📌 Но — в одном запросе.
❓ Попробуй решить задачу таким SQL:
🔍 Вопрос:
1) Почему он может вернуть неправильный результат?
2) В чём разница между
3) Как переписать его правильно?
✅ Разбор подвоха
💣 Подвох 1:
Когда ты делаешь
•
•
👉 Это может привести к тому, что:
•
• но в подзапросе
🔁 Как правильно:
1) Подзапрос должен использовать
2) Либо использовать
✅ Финальный корректный запрос:
🎯 Такой запрос честно покажет:
• Всех “молчунов” (0 постов)
• И самого активного автора (макс постов)
📌 Отлично подходит для собеседования или тех, кто считает, что "GROUP BY — это просто".
@sqlhub
📘 Условие
У тебя есть две таблицы:
users(id, name)
posts(id, user_id, title)
Вопрос:
Выведи всех пользователей, у которых нет ни одного поста,
а также пользователя, у которого больше всего постов.
📌 Но — в одном запросе.
❓ Попробуй решить задачу таким SQL:
SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0 OR COUNT(p.id) = (
SELECT MAX(cnt)
FROM (
SELECT COUNT(*) AS cnt
FROM posts
GROUP BY user_id
) t
);
🔍 Вопрос:
1) Почему он может вернуть неправильный результат?
2) В чём разница между
COUNT(*)
и COUNT(p.id)
? 3) Как переписать его правильно?
✅ Разбор подвоха
💣 Подвох 1:
COUNT(p.id)
пропускает NULL
Когда ты делаешь
LEFT JOIN
, для пользователей без постов p.id = NULL
.•
COUNT(*)
считает все строки (включая NULL) •
COUNT(p.id)
не считает строки, где p.id IS NULL
👉 Это может привести к тому, что:
•
COUNT(p.id) = 0
— действительно "нет постов" • но в подзапросе
SELECT COUNT(*)
считает иначе и даёт искаженную MAX(cnt)
🔁 Как правильно:
1) Подзапрос должен использовать
COUNT(p.id)
, чтобы сравнение было честным 2) Либо использовать
JOIN
вместо LEFT JOIN
в подзапросе, чтобы не попасть на "нулевых" пользователей✅ Финальный корректный запрос:
SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0
OR COUNT(p.id) = (
SELECT MAX(cnt)
FROM (
SELECT user_id, COUNT(p.id) AS cnt
FROM posts
GROUP BY user_id
) AS ranked
);
🎯 Такой запрос честно покажет:
• Всех “молчунов” (0 постов)
• И самого активного автора (макс постов)
📌 Отлично подходит для собеседования или тех, кто считает, что "GROUP BY — это просто".
@sqlhub
2200
13:01
14.05.2025
🧠 SQL-задача с подвохом (Oracle)
Тема: оконные функции, группировка, ловушка в агрегатах
📌 Задача:
Есть таблица
Пример данных:
🧩 Найти:
Для каждого региона — ту дату, в которую была вторая по величине сумма продаж.
Если в регионе меньше двух дат — не выводить его вовсе.
🎯 Подвох:
- нельзя использовать
- многие пытаются взять
✅ Ожидаемый результат:
🔍 Решение:
```sql
SELECT REGION, SALE_DATE, AMOUNT
FROM (
SELECT
REGION,
SALE_DATE,
AMOUNT,
DENSE_RANK() OVER (PARTITION BY REGION ORDER BY AMOUNT DESC) AS rnk,
COUNT(DISTINCT SALE_DATE) OVER (PARTITION BY REGION) AS cnt
FROM SALES
)
WHERE rnk = 2 AND cnt >= 2;
```
📌 **Объяснение подвоха:**
- `DENSE_RANK` гарантирует, что если есть одинаковые суммы, они получат один и тот же ранг
- `COUNT(DISTINCT SALE_DATE)` проверяет, что у региона хотя бы две разные даты (иначе регион исключается)
- Работает чисто на оконных функциях, без подзапросов с ROWNUM — идеально для Oracle
🧪 Проверь результат и попробуй адаптировать под похожие задачи с TOP-N логикой.
@sqlhub
Тема: оконные функции, группировка, ловушка в агрегатах
📌 Задача:
Есть таблица
SALES
со следующей структурой:
CREATE TABLE SALES (
ID NUMBER,
REGION VARCHAR2(20),
SALE_DATE DATE,
AMOUNT NUMBER
);
Пример данных:
| ID | REGION | SALE_DATE | AMOUNT |
|----|--------|-----------|--------|
| 1 | North | 01-JAN-24 | 100 |
| 2 | North | 02-JAN-24 | 120 |
| 3 | South | 01-JAN-24 | 90 |
| 4 | South | 03-JAN-24 | 200 |
| 5 | East | 01-JAN-24 | 150 |
| 6 | East | 02-JAN-24 | 100 |
🧩 Найти:
Для каждого региона — ту дату, в которую была вторая по величине сумма продаж.
Если в регионе меньше двух дат — не выводить его вовсе.
🎯 Подвох:
- нельзя использовать
LIMIT
, FETCH FIRST
, QUALIFY
и подзапросы с ROWNUM
напрямую (нужно решение через оконные функции Oracle)- многие пытаются взять
MAX(AMOUNT)
с OFFSET 1
, но в Oracle это не так просто✅ Ожидаемый результат:
| REGION | SALE_DATE | AMOUNT |
|--------|-----------|--------|
| North | 01-JAN-24 | 100 |
| South | 01-JAN-24 | 90 |
| East | 02-JAN-24 | 100 |
🔍 Решение:
```sql
SELECT REGION, SALE_DATE, AMOUNT
FROM (
SELECT
REGION,
SALE_DATE,
AMOUNT,
DENSE_RANK() OVER (PARTITION BY REGION ORDER BY AMOUNT DESC) AS rnk,
COUNT(DISTINCT SALE_DATE) OVER (PARTITION BY REGION) AS cnt
FROM SALES
)
WHERE rnk = 2 AND cnt >= 2;
```
📌 **Объяснение подвоха:**
- `DENSE_RANK` гарантирует, что если есть одинаковые суммы, они получат один и тот же ранг
- `COUNT(DISTINCT SALE_DATE)` проверяет, что у региона хотя бы две разные даты (иначе регион исключается)
- Работает чисто на оконных функциях, без подзапросов с ROWNUM — идеально для Oracle
🧪 Проверь результат и попробуй адаптировать под похожие задачи с TOP-N логикой.
@sqlhub
2600
11:15
13.05.2025
🛢️ SQL-задача с подвохом: GROUP BY и скрытая ловушка
Условие:
Есть таблица
| id | customer_id | amount | status |
|-----|-------------|--------|-----------|
| 1 | 101 | 200 | completed |
| 2 | 102 | 150 | NULL |
| 3 | 101 | 300 | completed |
| 4 | 103 | NULL | completed |
| 5 | 102 | 100 | completed |
| 6 | 101 | 250 | NULL |
Задача: найти всех клиентов, у которых сумма заказов больше 500.
Ты пишешь запрос:
❓ Вопрос:
Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где
🔍 Подвох:
На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты:
1️⃣ Что происходит с NULL в `amount`?
В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит:
- Заказ id=4 (`amount = NULL`) не участвует в суммировании.
- Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL.
2️⃣ Считаем по каждому клиенту:
- customer_id=101:
- id=1: 200
- id=3: 300
- id=6: 250
Итого: 200 + 300 + 250 = 750
- customer_id=102:
- id=2: 150
- id=5: 100
Итого: 150 + 100 = 250
- customer_id=103:
- id=4: NULL (игнорируется)
Итого: 0
3️⃣ Кто попадёт в результат:
Только customer_id=101 (с суммой 750 > 500).
---
✅ Результат:
| customer_id | total |
|-------------|--------|
| 101 | 750 |
---
💥 Подвох #2:
Допустим ты случайно написал:
Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой.
➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL.
Это частая ловушка:
COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата).
---
🛠 Что ещё важно:
• Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:
⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.
✅ Вывод:
- ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы.
- ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие).
- ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО.
- ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE.
💡 Бонус-вопрос:
Что будет, если заменить
@sqlhub
Условие:
Есть таблица
orders
:| id | customer_id | amount | status |
|-----|-------------|--------|-----------|
| 1 | 101 | 200 | completed |
| 2 | 102 | 150 | NULL |
| 3 | 101 | 300 | completed |
| 4 | 103 | NULL | completed |
| 5 | 102 | 100 | completed |
| 6 | 101 | 250 | NULL |
Задача: найти всех клиентов, у которых сумма заказов больше 500.
Ты пишешь запрос:
SELECT customer_id, SUM(amount) as total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;
❓ Вопрос:
Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где
amount
или status
— NULL
?🔍 Подвох:
На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты:
1️⃣ Что происходит с NULL в `amount`?
В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит:
- Заказ id=4 (`amount = NULL`) не участвует в суммировании.
- Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL.
2️⃣ Считаем по каждому клиенту:
- customer_id=101:
- id=1: 200
- id=3: 300
- id=6: 250
Итого: 200 + 300 + 250 = 750
- customer_id=102:
- id=2: 150
- id=5: 100
Итого: 150 + 100 = 250
- customer_id=103:
- id=4: NULL (игнорируется)
Итого: 0
3️⃣ Кто попадёт в результат:
Только customer_id=101 (с суммой 750 > 500).
---
✅ Результат:
| customer_id | total |
|-------------|--------|
| 101 | 750 |
---
💥 Подвох #2:
Допустим ты случайно написал:
HAVING SUM(amount) IS NOT NULL AND SUM(amount) > 500;
Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой.
➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL.
Это частая ловушка:
COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата).
---
🛠 Что ещё важно:
• Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:
WHERE status = 'completed'
⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.
✅ Вывод:
- ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы.
- ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие).
- ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО.
- ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE.
💡 Бонус-вопрос:
Что будет, если заменить
SUM(amount)
на COUNT(amount)
в SELECT и HAVING? И как это повлияет на клиентов с NULL значениями?@sqlhub
2800
13:03
12.05.2025
imageИзображение не доступно для предпросмотра
SQL Flow позиционируется как «DuckDB для потоковых данных» — лёгковесный движок stream-обработки, позволяющий описывать весь pipeline единственным языком SQL и служащий компактной альтернативой Apache Flink.
🔍 Ключевые возможности:
- Источники (Sources): Kafka, WebSocket-стримы, HTTP-webhooks и др.
- Приёмники (Sinks): Kafka, PostgreSQL, локальные и S3-подобные хранилища, любые форматы, которые поддерживает DuckDB (JSON, Parquet, Iceberg и т.д.).
- SQL-обработчик (Handler): встраивает DuckDB + Apache Arrow; поддерживает агрегаты, оконные функции, UDF и динамический вывод схемы.
- Управление окнами: in-memory tumbling-windows, буферные таблицы.
- Наблюдаемость: встроенные Prometheus-метрики (с релиза v0.6.0).
🔗 Архитектура
Конвейер описывается YAML-файлом с блоками `source → handler → sink`.
Во время выполнения:
1. Source считывает поток (Kafka, WebSocket …).
2. Handler выполняет SQL-логику в DuckDB.
3. Sink сохраняет результаты в выбранное хранилище.
# получить образ
docker pull turbolytics/sql-flow:latest
# тестовая проверка конфигурации
docker run -v $(pwd)/dev:/tmp/conf \
-v /tmp/sqlflow:/tmp/sqlflow \
turbolytics/sql-flow:latest \
dev invoke /tmp/conf/config/examples/basic.agg.yml /tmp/conf/fixtures/simple.json
# запуск против Kafka
docker-compose -f dev/kafka-single.yml up -d # поднять Kafka
docker run -v $(pwd)/dev:/tmp/conf \
-e SQLFLOW_KAFKA_BROKERS=host.docker.internal:29092 \
turbolytics/sql-flow:latest \
run /tmp/conf/config/examples/basic.agg.mem.yml --max-msgs-to-process=10000
▪ Github
@sqlhub
4100
10:55
09.05.2025
imageИзображение не доступно для предпросмотра
💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV и MongoDB, работать с Git как с хранилищем данных и даже запускать SQL-запросы прямо в браузере через WebAssembly.
Что отличает GlueSQL от классических СУБД?
- Поддержка schemaless-данных
- Встроенные адаптеры для 10+ форматов
- Возможность добавлять свои хранилища через реализацию двух traits на Rust
Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно
🤖 GitHub
@sqlhub
Что отличает GlueSQL от классических СУБД?
- Поддержка schemaless-данных
- Встроенные адаптеры для 10+ форматов
- Возможность добавлять свои хранилища через реализацию двух traits на Rust
Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно
cargo add gluesql
и уже можно писать SQL-запросы к данным в памяти. 🤖 GitHub
@sqlhub
5100
11:28
06.05.2025
🧩 Задача для SQL-аналитиков: "Пропавшие продажи"
📖 Описание задачи
У вас есть таблица
Каждый день формируется отчёт, где суммируются продажи по дням:
✅ Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли.
📝 Ваша задача:
1. Найти, какие записи "исчезли" из отчёта, если данных в таблице
2. Определить, почему эти записи больше не попадают в итоговый запрос.
3. Исправить отчёт, чтобы сумма снова стала 1,000,000.
Ограничения:
- Таблица не изменилась по количеству строк.
- Никто не менял код запроса.
-
Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации.
🕵️ Что проверяет задача:
- Знание SQL-агрегации
- Понимание NULL и работы SUM
- Умение анализировать запросы «не через код», а через их результат
- Навык находить «скрытые» ошибки данных (например,
💡 Решение:
При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле на NULL).
Итоговый запрос:
```sql
SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
```
не учитывает строки, где `sale_date IS NULL`, потому что игнорирует NULL как отдельную группу (не попадает ни в один существующий `sale_date`).
Чтобы увидеть эти записи:
```sql
SELECT sale_date, COUNT(*), SUM(quantity * price)
FROM sales
GROUP BY sale_date;
```
Для восстановления суммы нужно добавить обработку NULL, например:
```sql
SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY COALESCE(sale_date, 'unknown');
```
✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию .
🎯 Эта задача учит:
✅ Всегда думать о данных, а не только о коде
✅ Проверять поля на NULL даже там, где их не ожидаешь
✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос
🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации!
@sqlhub
📖 Описание задачи
У вас есть таблица
sales
, где хранятся данные о продажах:
CREATE TABLE sales (
sale_id INT PRIMARY KEY,
sale_date DATE,
product_id INT,
quantity INT,
price DECIMAL(10,2)
);
INSERT INTO sales (sale_id, sale_date, product_id, quantity, price) VALUES
(1, '2024-01-01', 101, 1, 100.00),
(2, '2024-01-02', 102, 2, 150.00),
-- ...
-- остальные данные
;
Каждый день формируется отчёт, где суммируются продажи по дням:
SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
✅ Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли.
📝 Ваша задача:
1. Найти, какие записи "исчезли" из отчёта, если данных в таблице
sales
фактически не удаляли.2. Определить, почему эти записи больше не попадают в итоговый запрос.
3. Исправить отчёт, чтобы сумма снова стала 1,000,000.
Ограничения:
- Таблица не изменилась по количеству строк.
- Никто не менял код запроса.
-
sale_date
, quantity
, price
остались без изменений.Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации.
🕵️ Что проверяет задача:
- Знание SQL-агрегации
- Понимание NULL и работы SUM
- Умение анализировать запросы «не через код», а через их результат
- Навык находить «скрытые» ошибки данных (например,
sale_date
стал NULL)💡 Решение:
При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле
sale_date
Итоговый запрос:
```sql
SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
```
не учитывает строки, где `sale_date IS NULL`, потому что
GROUP BY
Чтобы увидеть эти записи:
```sql
SELECT sale_date, COUNT(*), SUM(quantity * price)
FROM sales
GROUP BY sale_date;
```
Для восстановления суммы нужно добавить обработку NULL, например:
```sql
SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY COALESCE(sale_date, 'unknown');
```
✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию
unknown
🎯 Эта задача учит:
✅ Всегда думать о данных, а не только о коде
✅ Проверять поля на NULL даже там, где их не ожидаешь
✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос
🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации!
4300
09:37
06.05.2025
close
С этим каналом часто покупают
Отзывы канала
keyboard_arrow_down
- Добавлен: Сначала новые
- Добавлен: Сначала старые
- Оценка: По убыванию
- Оценка: По возрастанию
4.9
1 отзыва за 6 мес.
Очень хорошо (100%) За последние 6 мес
n
**talia.kombarova@********.com
на сервисе с сентября 2024
09.12.202418:14
4
Оперативное размещение
Показать еще
Лучшие в тематике
Новинки в тематике
Статистика канала
Рейтинг
36.6
Оценка отзывов
4.9
Выполнено заявок
102
Подписчики:
32.9K
Просмотры на пост:
lock_outline
ER:
5.9%
Публикаций в день:
1.0
CPV
lock_outlineВыбрано
0
каналов на сумму:0.00₽
Подписчики:
0
Просмотры:
lock_outline
Перейти в корзинуКупить за:0.00₽
Комментарий