Чем отличаются WHERE и HAVING?

Это один из самых популярных вопросов на стажера, джуна и иногда мидла de/da. Я думаю, практически все знают что нужно отвечать.

Вот, например, в тг канале @data_analysis_it был дан такой ответ https://news.1rj.ru/str/data_analysis_it/83 :

Чем отличаются WHERE и HAVING?
WHERE
• GROUP BY не обязателен
• Применяется к отдельным строкам таблицы.
• Не может использовать агрегатные функции
HAVING
• GROUP BY обязателен
• Применяется к результатам агрегатных вычислений.
• Может использовать агрегатные функции

Все четко и понятно.

Deepseek даст такой краткий ответ:

Кратко:
1. WHERE:
• Фильтрует строки до группировки или агрегации.
• Работает с отдельными строками.
• Не может использоваться с агрегатными функциями.
2. HAVING:
• Фильтрует группы или результаты агрегации после группировки.
• Работает с группами строк или агрегатными функциями.
• Используется только с GROUP BY или агрегатными функциями.
Главное: WHERE — для строк, HAVING — для групп. 😊

Примерно тоже самое.
Это база, ее обязательно надо знать. В целом такого ответа на собеседовании будет достаточно.

НО! Но я вам хочу рассказать о важном нюансе, о котором очень много инженеров не знает:

HAVING можно использовать без GROUP BY!

Пример:

select max(campaign_id) from public.costs
having max(campaign_id)>2
--Результат 100.

select count(campaign_id) from public.costs
having count(campaign_id)>1000
--Результат 39300

В примере HAVING применяется не к группам, а ко всей таблице в целом, в данном случае группой является вся выборка. То есть в select-e выполняется просто функция, допустим count(*) , ко всем данным, но и еще можно сразу добавить фильтр по этому значению.
Вроде ничего важного, вряд ли кто-то таким образом будет использовать having без group by, просто прикольная фишка.
На самом деле данная фишка используется.

На моей прошлой работе, в одном красном банке, в архитектуре ETL была настроена система Eventwait-ов (флагов) таким образом:

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

Каждые 5 минут запускается мониторинговый поток, который запускает кучу селектов и проверяет готовы ли источники.
Код там был примерно такой:

-- проверка логов за сегодня по каждой таблице
select count(t2.job_id)
from control.workflow t1 inner join control.log_loading t2 ...
where t1.workflow_name = t2.workflow_name
and t2.loading_id = ($$p_ loading_id)
and t2.status = 'succeeded'
...
and t1.table_name = 'table_name'
and t2.operation_day = to_date('$$p_operation_day","yyyymmdd')
having count(t2.job_id) >= 

-- смотрим сколько всего потоков должно грузить таблицу (число фиксированное)
(select count(workflow_name)
from control.md_workflow t1
where table_owner = 'table_owner'
and table_name = 'table_name')

В этом запросе у нас идет сравнение по каждой таблице-источнику за отчетный день – сколько отработало сегодня потоков для ее загрузки и сколько потоков вообще грузит таблицу. Пока у нас все потоки за сегодня не прогрузят таблицу, проверочный select выдаст 0 строк. И потоки в слое витрин данных не грузят свои таблицы, пока не готовы их источники (пока в результате запроса нет строк).
Если в результате какого-нибудь select-a у нас есть число ( чаще, просто 1, тк в основном одну таблицу грузит один поток), то значит этот флаг пришел. Как только все флаги для определенного потока пришли, запускается расчет таблицы из слоя витрин.

Я не скажу, что это хорошая система. Это скорее легаси, сейчас делается по-другому. Но примерная система есть во многих «старых» компаниях.

В общем, GROUP BY для HAVING-a не обязателен.


Кстати, если у deepseek-а спросить об этом напрямую, он скажет, что можно использовать having без group by, но с оговоркой:

В большинстве СУБД (например, PostgreSQL, MySQL) это допустимо, но в некоторых (например, Oracle) может вызвать ошибку»

От себя добавлю - в Oracle это тоже работает. Так что всего проверяйте ответы нейронки😊

#Вопросы_с_собесов

Предыстория: 📚

Книги я особо не читаю. Начал читать в 20+ лет и только в последний год читаю одну книгу в два месяца. Читаю художественную литературу (нравится больше всего), техническую и историческую.

Бизнесовую/саморазвития/психологическую литературу не очень люблю. Как-то начал читать всеми известную «Богатый папа, бедный папа». Прочитал страниц 15 и бросил. Банальщина... 🙄

Недавно купил еще одну классику «Думай и богатей» (авт. Наполеон Хилл), просто ради интереса. Это похоже на прародителя инфоцыган, там есть основные заповеди для достижения цели – мечтай, воображай, верь и перечитывай эту книгу каждый день.. 🫢
Но читается легко. Там приводятся в пример истории реальных людей, и это иногда интересно. 🧐

Зачем я об этом вообще пишу:
Книга 1937 года! И вот вчера я наткнулся на такой абзац ( фото в закрепе).

Почти 100 лет назад в Америке уже учили, как составлять резюме и продавать себя. Многое из рекомендаций сейчас, конечно, неактуально – печать резюме на дорогой бумаге, класть его в очень дорогую, красивую папку, делать фото в крутой студии и т.д.

Просто как факт, 100 лет назад в США уже была корпоративная культура, многие люди уже были заряжены на построение успешной карьеры. 💼✨

А до нашей страны это дошло недавно. Ну, наверное, лет 20 назад (можете поправить)..
В России всё только зарождается, и у нас есть большие перспективы преуспеть в корпоративной культуре. Но считаю нормальным и очень полезным перенимать опыт западных стран, модифицировать, улучшать и применять его у нас. 🌍🚀

Что думаете? 🤔 Может, у вас есть свои примеры или мысли на эту тему? 💭

#книги

Вопросы про джоины:

Буду делать серию постов про самые популярные вопросы по sql секции.
Я думаю, на любом собесе будут вопросы про джоины. Давайте разберем популярные вопросы/задачи:

1) Минимальное и максимальное количество строк в результате джоинов.

Допустим левая таблица t1 (поле id) – 100 строк, правая таблица t2 (id) – 10 строк

inner join:
Min – 0 строк. Если никаких пересечений нет, в двух таблицах нет одинаковых id.
Max – 1000 строк. Если в двух таблицах только одно значение (например, 1). Просто делаем перемножение.

left join:
Min – 100 строк. Если никаких пересечений нет, в результате будут все значения из левой таблицы.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

right join:
Min – 10 строк. Если никаких пересечений нет, в результате будут все значения из правой таблицы
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

full join:
Min – 100 строк. Вот этот момент важно понять, на нем часто допускают ошибки. Минимальное количество при full join будет – количество строк из большей таблицы. Например, в левой таблице значения от 1 до 100, а в правой от 1 до 10.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

cross join:
Min и Max – 1000 строк. Делаем перемножение.

2) Сколько строк вернет операция FULL JOIN, если известно следующее:
INNER JOIN - 6 строк
LEFT JOIN - 10 строк
RIGHT JOIN - 12 строк

Давайте попробуем ее решить без запоминаний и просто понять.
Если вспомнить круги Эйлера (о их корректности будет отдельный пост):
FULL JOIN – это левая непересекающаяся часть + средняя пересекающаяся часть + правая непересекающаяся часть. Просуммируем эти три части:
FULL JOIN = (LEFT JOIN - INNER JOIN) + (INNER JOIN) + (RIGHT JOIN - INNER JOIN)
FULL JOIN = (10 - 6) + (6) + (12-6)
FULL JOIN = 16

Также если раскрыть скобки, то можно понять, что по сути
FULL JOIN = (RIGHT JOIN) + (LEFT JOIN) – (INNER JOIN) = 10 + 12 – 6 = 16

3) Заполнение результата после всех видов джоинов.
Такую задачу тоже часто дают, здесь важно не запутаться. Я приложил скрин с результатами джоинов, внимательно изучите. Особенно обратите внимание на результат соединения дублей и null-ов.

Расскажите какие у вас были интересные вопросы про джоины: 💭


#Вопросы_с_собесов

Вакансия: Senior DWH разработчик
Компания: Магнит TECH
Предполагаемая вилка: от 270к на руки
Период собеседования: Декабрь 2024
Формат работы: Удаленная работа
Этапы собеседований:
HR -> Tech Interview -> Offer
Краткая справка о процессе интервью:
Собеседовал тех лид команды, который был очень технически подкован. Тех лид задавал интересные вопросы про опыт работы, моделирование, индексы, оптимизацию, план запроса и дал пару задачек. То есть он не просто задавал банальные вопросы, а копал все глубже и глубже, чтоб понять уровень знаний. И большой респект, что сам давал какие-то ответы и объяснял технические нюансы.

Более подробно:

Я рассказал о своем опыте. Тех лида заинтересовал опыт с созданием с нуля витрины данных. Он спрашивал про выбор модели, как я оценивал объем данных и прогнозировал что будет через год. Спрашивал про типы полей, размерности, индексы.

Блок про моделирование. Снежинка/звезда/ - где что используются, плюсы и минусы. Data vault- что это и за счет чего достигается гибкость.

Большой блок вопросов про внутренности БД - про план запроса, статистику, кардиналити, какие бывают методы доступа к таблицам. Индексы – что это и какие виды знаю, чем отличается бинарное дерево от сбалансированного, сколько уровней в сбалансированном дереве, битмап индекс. Методы физического соединения – какие есть виды(по каждому виду задавал много вопросов), какой метод соединения предпочтителен при соединении больших таблиц (важно учитывать какая СУБД), что такое хэш мапа, почему по ней быстрый поиск.

Когда говорили про переезд в облако, собеседующий сказал, что до конца не решили на какой стек они переедут. Активно занимаются этим вопросом. Смотрят на опыт других больших компаний. DWH на GP не хотят мигрировать. Сказал, что очень много косяков с GP и он считает, что многие компании тоже от GP откажутся.
В конце дал две несложных задачки на джоины и оконки.

Через неделю пришел отказ, так как магнит тех переезжает в облако и им нужен более опытный инженер (ближе к архитектору), который также шарит за S3 и желательно Impala.

Люблю такие собесы – получается бесплатная проверка знаний + собеседующий много всего сам объяснил и сказал, что можно изучить. Отношение к компании улучшилось.
Еще из интересного вакансию нашел не на hh, а на их сайте и сам отправил свое резюме.

*идея позаимствована у https://news.1rj.ru/str/get_rejected

#Собес

Недавний пост про джоины набрал много просмотров и репостов. Значит такая информация интересна.
Продолжим наваливать базу 🤝

Популярные вопросы с собесов (lvl junior):

1) В какой последовательности СУБД на самом деле выполняет команды запроса:

select distinct
from
join
where
group by
having
order by
limit

Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода

Более удобный вид:

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT

2) UNION ALL vs UNION - в чем разница?

UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные

UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи


Также могут дать простую задачку:

Даны таблицы T1(col1, col2), T2(col1, col3).
Наполнение таблиц:

T1
(13, 15)
(13, 15)
(13, 15)

T2
(13, 15)
(13, 14)

Будет ли работать запрос? Если будет работать, то сколько строк вернет?

SELECT * FROM T1
UNION
SELECT * FROM T2

Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15

3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят 😄

UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.

ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу


Подскажите плз вам интересна эта тема? Предлагайте свои варианты по чему можно навалить базы?


#Вопросы_с_собесов #база #sql #jun

Ч.1.

INSERT и UPDATE и их влияние на прием данных
«С чем сложнее работать базе данных — INSERT с данными или UPDATE?»

Сначала вы можете подумать: «А какое это имеет значение? Они служат разным целям, верно?» INSERT добавляет новые строки и UPDATE изменяет существующие — дело закрыто. Когда вы загружаете данные в систему — синхронизируете внешние источники, вставляете данные или обновляете аналитические таблицы — выбор между INSERT и UPDATE может существенно повлиять на производительность и масштабируемость вашей базы данных.

Операция INSERT
На первый взгляд, INSERT кажется, все просто — добавить новую строку в систему. Но если заглянуть под капот, то все сложнее, чем может показаться.

Индексы
Когда вы вставляете строку, это не просто добавление данных в таблицу. Движок базы данных также должен обновить все связанные индексы. Если вы думаете об индексах как о каталогах, то каждая новая запись должна быть аккуратно помещена на свое правильное место, гарантируя, что каталог останется отсортированным и полезным.

Больше индексов означает больше накладных расходов. Каждый дополнительный индекс требует дополнительных усилий для расчета, поиска и хранения новых данных. В то время как индекс с одним столбцом обновляется относительно быстро, составные или уникальные индексы (например, (user_id, created_at)) добавляют сложности и задержки.

💡 Избегайте слепого добавления индексов. Каждый из них повышает производительность запросов, но замедляет INSERT. Стремитесь к балансу.

Ограничения и триггеры
Прежде чем новые данные официально попадут в таблицу, они должны пройти несколько проверок целостности. Эти ограничения включают внешние ключи для обеспечения связей, UNIQUE ограничения для предотвращения дублирования записей и NOT NULL требования для обеспечения качества данных. Если схема включает вычисляемые столбцы, база данных должна вычислять их значения на лету.

Кроме того, триггеры могут выполнять пользовательскую логику во время вставки, например, ведение журнала или каскадные обновления (или любую другую пользовательскую логику, которая у вас может быть). Хотя они полезны, они могут значительно увеличить рабочую нагрузку, особенно для сложных схем данных.

Параллелизм
INSERT Операции, как правило, хорошо взаимодействуют с блокировками, используя минимальные механизмы блокировки, такие как блокировки строк или страниц . Однако параллелизм все еще может вызывать головную боль в системах с высокой нагрузкой. Если несколько потоков одновременно пытаются вставить данные в одну и ту же таблицу или раздел, может возникнуть конфликт блокировок. Или, что еще хуже, взаимоблокировки — когда две транзакции блокируют друг друга на неопределенный срок.

💡 Для сред с высоким уровнем параллелизма:
1. Используйте пакетирование для массовых вставок.
2. Рассмотрите возможность секционирования или сегментирования для распределения нагрузки.

Раздувание хранилища
Массовые вставки или частые небольшие вставки могут со временем привести к раздуванию таблицы при увеличении ее физического размера, даже если объем полезных данных в таблице может и не увеличиться существенно:

Фрагментация : частые вставки могут фрагментировать базовое хранилище, снижая производительность последующих операций чтения и записи.
Раздувание : таблицы без надлежащего обслуживания (например, периодической очистки или архивации) могут неоправданно разрастаться, занимая место в хранилище и снижая производительность.
💡 Планируйте регулярные задачи по обслуживанию, такие как VACUUM, ANALYZE или архивирование, чтобы бороться с раздуванием и фрагментацией. Однако будьте осторожны — эти операции могут полностью заблокировать вашу базу данных.

Ч.2.

Операция UPDATE
При UPDATE изменяются уже существующие — и вот тут-то все становится сложнее. UPDATE Операции часто задействуют несколько подсистем в базе данных, что делает их ресурсоемкими.

Нахождение строк
Каждый UPDATE начинается с поиска. Механизм базы данных должен найти точные строки, которые соответствуют WHERE предложению.

Если WHERE предложение нацелено на индексированные столбцы, это может быть относительно эффективно. Однако, если запрос фильтрует неиндексированные столбцы, движку может потребоваться некоторое время для сканирования всей таблицы. На небольших наборах данных это управляемо, но по мере роста таблицы процесс поиска может стать мучительно медленным.

💡 Плохо оптимизированные запросы или отсутствующие индексы могут увеличить стоимость поиска строк, что значительно повлияет на производительность. Опять же, оптимизацию часто нужно выполнять в пространстве между монитором и креслом.

Индексированные столбцы
Хотя индексы отлично подходят для ускорения поиска, при их изменении они добавляют значительные накладные расходы. База данных должна не только обновить строку, но и пересмотреть каждый связанный индекс. Следовательно, обновление индексированных столбцов может быть медленным.

Для составных индексов сложность умножается. Обновление одного значения может привести к пересчету и изменению положения записи индекса. Чем больше индексов привязано к столбцу, тем больше времени база данных тратит на перетасовку данных, замедляя UPDATE.

Параллелизм
В отличие от относительно дружественных к параллелизму операций INSERT, UPDATE операции могут быть блокировочными. Чтобы обеспечить целостность данных, база данных часто блокирует обновляемые ею строки, не давая другим операциям изменять их одновременно. Для небольших таблиц с низким трафиком это нормально. Но в средах с высоким параллелизмом эти блокировки могут перерасти в тех же двух подозреваемых: конфликт блокировок или взаимоблокировки.

💡 Минимизируйте область блокировок, ограничив строки, на которые нацелены запросы UPDATE (предложения WHERE — ваши лучшие друзья). Пакетные обновления также могут помочь уменьшить конкуренцию.

Журналы транзакций
Базы данных ведут журналы транзакций для обеспечения согласованности и поддержки откатов. Хотя INSERTи UPDATE запись в журнал транзакций, UPDATE как правило, более многословна.

Это особенно актуально для баз данных, таких как PostgreSQL, которые используют Multi-Version Concurrency Control (MVCC) . Здесь UPDATE не перезаписывает существующую строку, а создает новую версию строки и помечает старую как «мертвую». Этот процесс обеспечивает согласованность и поддерживает параллельные чтения, но со временем может привести к фрагментации и потребовать регулярных VACUUM операций по освобождению хранилища.

Что сложнее?
Если вы добавляете новые строки с небольшим количеством индексов или без них и минимальными ограничениями, INSERT обычно это будет более простым вариантом. Обычно это проще и понятнее, когда данные свежие и таблица не сильно индексирована. Но как только в дело вступают индексы, триггеры и высокая степень параллелизма, INSERT это может начать нагружать ресурсы базы данных.

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

Подводя итоги
Выбор между INSERT и UPDATE во многом зависит от вашего варианта использования и структуры вашей базы данных. Например, если вы имеете дело с большими объемами обновлений, вы можете рассмотреть альтернативные стратегии, такие как вставка новой строки и удаление старой, вместо выполнения тяжелого обновления, особенно если обновления рискуют фрагментировать таблицу или повлиять на несколько индексов.

Задача

Есть две таблицы из одного поля. В левой таблице table_1 - 4 строки, во всех null. В правой таблице table_2 - 10 строк, во всех также null.

Сколько строк вернет запрос из этих двух таблиц в результате соединений:

A - inner join
Б - left join
В - right join
Г - full join
Д - cross join


#задача