Comments 18
Спасибо. Может небольшое уточнение только. В статье написано:
HAVING — Обязательно использует агрегатные функции
Это не совсем так, HAVING может фильтровать и по столбцам из GROUP BY без агрегатов:
SELECT department, COUNT(*)
FROM employees
GROUP BY department
HAVING department <> 'HR';
Зачем это на Хабре? Это ж пересказ документации просто.
А Хабр вообще-то и задумывался как место, где разработчики делятся знаниями - в том числе пересказывают и структурируют уже известное. Если критерий «есть в документации» - давай снесём половину ресурса, начиная с туториалов по Python.
Зачем это на Хабре?
Чтобы набить публикаций ну хоть чем-нибудь.
Причём порой из-под палки, по принуждению - слушатель курсов, разместивший публикацию в составе аккаунта курса, получает дополнительный профит (или НЕ разместивший - дополнительный геморрой). Пример такого аккаунта не привожу - вы скорее всего знаете, о ком я..
И ладно хотя бы предварительно выбрали да почитали предыдущие статьи о ровно том же самом, включая комментарии и критику, так ведь нет - мы ж самые умные и пишем исключительный эксклюзив! Что забавно - пишут-то вовсе не специалисты в этой области, не SQL-щики, пишут исключительно аналитики. Мёдом им мазано, что ли? А впечатление по прочтении - ну просто рассказ о том, как автор в три годика первый раз сам сходил на горшок без помощи мамы, и при этом без фатальных последствий для гигиены.
У скольких, скопипастивших "порядок выполнения запроса", я спросил, где в нём оконные функции.. вы думаете, хоть кто-нибудь ответил? Никто. Потому что они просто НЕ ЗНАЮТ. Потому что на самом деле публикуют не свои знания, а копию чужих - а там ответа на этот вопрос нет.
по моему в начале статьи четко написано, что это про мой личный опыт и опыт моих знакомых. и с каких пор у хабра требования к статьям как у scopus?
Я бы переформулировал вопрос. С каких пор Хабр вдруг стал площадкой для некачественного (см комментарий ниже про разные СУБД и проч) пересказа документации и прописных истин? 😉
это про мой личный опыт
Порядок выполнения запросов вы составили исключительно на основании своего личного опыта? Тогда вы должны без проблем ответить на вопрос, где в нём оконные функции. Да так, чтобы стало понятно, почему аргументом оконной функции может быть агрегатная, и возможно ли наоборот. Уж не игнорируйте этот вопрос, ответьте на него, а?
А то ведь насчёт "личного опыта" мы можем и не поверить..
Оконные функции идут после агрегаций, агрегаты внутри возможны, наоборот нет. Я расписала упрощенную схему, которую чаще и спрашивают, и не писала про всякие нюансы с СУБД, это тянет на отдельную статью. Это не про sql статья, а про возможные вопросы на собеседовании по sql.
Оконные функции идут после агрегаций
То есть перед HAVING в вашем списке шагов выполнения запроса, так, что ли? Но тогда их можно было бы использовать в условиях предложения HAVING.. а на самом-то деле нельзя. Неувязочка получается.
Я расписала упрощенную схему
Ну да.. расписали всё-всё, но почему-то кроме исключительно оконных функций. Интересно, почему вы выбрали именно такой способ упростить?
Это не про sql статья, а про возможные вопросы на собеседовании по sql.
Как я уже указывал, вы далеко не первый аналитик, написавший статью по этой теме и именно с таким уклоном. Большинство из них утверждает, что про оконные функции на собеседованиях - спрашивают. Более того - что на оконных функциях построено очень много аналитики.
автор в три годика первый раз сам сходил на горшок без помощи мамы, и при этом без фатальных последствий для гигиены.
Отличная аналогия! Запомнил и плюсанул👍
Порядок выполнения операторов в запросе
Укажите в этой схеме место выполнения ОКОННЫХ функций.
5. HAVING - фильтрация групп
6. SELECT - выбор полей
Да щазз! Есть СУБД, которые допускают использование алиасов полей выходного набора в предложении HAVING (напр. MySQL/MariaDB). При указанном порядке выполнения это совершенно невозможно.
Результат CTE не сохраняется в базе данных и доступен только для одного последующего оператора SELECT, INSERT, UPDATE, DELETE или MERGE.
Забыли последующие CTE.
Поддерживает рекурсивные запросы (с помощью WITH RECURSIVE)
SQL Server прекрасно обходится без дополнительного RECURSIVE.
полезно для работы с иерархическими данными (например, деревьями)
С любыми графами - деревьями применение не ограничивается.
спасибо за статью. Не понимаю, откуда столько негатива - на Хабре сейчас каждый день рождается куча однотипных статей, у которых рейтинг остается 0 или даже плюсы кто-то ставит. Здесь же мне, как бэкендеру редко сталкивающемуся с продвинутым SQL, захотелось добавить в закладки и внимательно почитать на досуге и саму статью и комментарии, освежить в памяти "базу".
К тому же, автору указали на неточности, автор принял к сведению - вот и польза от Хабра :)
Всяко лучше, чем очередной нейротекст про то, как Карпатый роняет сосиску рынок разработки
автору указали на неточности, автор принял к сведению
Ну действительно заботящиеся о читателе авторы вносят коррективы в текст, особенно когда в комментариях им указывают на фактические ошибки. Потому как заставить читателя сперва прочитать неверные или лишь частично верные факты в статье, а потом выискивать коррективы по комментариям - это не совсем правильно со стороны автора, не так ли?
А негатив... ну наверное это негатив от снижения уровня на Хабре в общем, который копится-копится, а потом просто выплёскивается на отдельных авторов, порой и правда в несколько увеличенном объёме.
Спасибо! Тоже не поняла негатив, ну да ладно) коррективы внесу как время будет
Эти три буквы никого не оставляют равнодушными