Интересно, что в голосовании перевалил сильно вариант: "Это положительное технологическое нововведение, которое следует развивать". Стоит задуматься либо у нас общество настолько свободное в своих нравах, либо аморальное.
Поддерживаю, мы сейчас вообще уходим от рекурсивных CTE в пользу развертывания кода по конечному числу итераций. Но в список рекомендаций пока не вошёл, т к должно пройти время после использования подхода для его оценки.
Я не самый авторитетный и мы часто обсуждаем и спорим особенно на ревью решения. Мы просто не ставим авторитетов выше себя: всегда все перепроверяем. В данном случае, книга хорошая, но местами её подходы естественным образом устарели. И добавлю (уже где-то писал): любая книга/публикация и т д есть отражение опыта его/её автора/авторов, а значит заранее ограничена именно опытом конкретных специалистов. Т е где-то материал будет полезен, а где-то не очень. А общая унификация вообще может жить только в вакууме и в реалии весьма вредна. И книги авторитетов не являются исключением.
Вас тоже с праздниками! Данный пример для си-языков, а здесь мы T-SQL рассматриваем. И не смотря на почетную книженцию, в данном примере есть риск, что из цикла можно вообще никогда не выйти. Т е не смотря на авторитет автора и с учетом риска бесконечного зацикливания кода, позволю себе не согласиться. Может раньше так и было можно, а сейчас больше за предсказуемый по выполнению и безопасный код.
Жаль, что не смог Вас убедить. Кстати, CTE тоже лучше на лево и направо не раскидываться особенно если таблицы-участницы большие. Но опять же понятие "большие" относительно.
Понимаю, у всех нагрузка большая. Потому я в основном пишу на выходных. Но в любом случае Ваш материал будет интересно изучить, потому надеюсь и буду ждать публикации. Спасибо!
select 1 показывает, что проблем с производительностью СУБД нет. Значит, все остальные рекомендации про оптимизацию являются неверными раз найдены исключения, опровергающие это.
Лично я не запрещаю, а рекомендую. Это раз. А во-вторых, пока специалист не обжёгся на конкретном сценарии да ещё и со своим опытом, его очень сложно переубедить. Потому если мои аргументы Вас не переубедили и мы не пересекаемся по проекту, то конечно решение как делать остаётся за Вами и Вашей командой.
Можно добавить отдельными запросами во временную таблицу и потом с этой таблицей сделать либо group by, либо distinct-смотря сколько полей нужно сделать уникальными. Если 1-3 поля-то group by, а если больше, то distinct (про distinct говорится в п.12)
Да, лень - двигатель прогресса, а удовольствие - творчества.
Интересно, что в голосовании перевалил сильно вариант: "Это положительное технологическое нововведение, которое следует развивать". Стоит задуматься либо у нас общество настолько свободное в своих нравах, либо аморальное.
Взаимно!
Имелось в виду в общем
Мандарины в голове уже.
С Новым Годом!
Поддерживаю, мы сейчас вообще уходим от рекурсивных CTE в пользу развертывания кода по конечному числу итераций. Но в список рекомендаций пока не вошёл, т к должно пройти время после использования подхода для его оценки.
Я не самый авторитетный и мы часто обсуждаем и спорим особенно на ревью решения. Мы просто не ставим авторитетов выше себя: всегда все перепроверяем. В данном случае, книга хорошая, но местами её подходы естественным образом устарели. И добавлю (уже где-то писал): любая книга/публикация и т д есть отражение опыта его/её автора/авторов, а значит заранее ограничена именно опытом конкретных специалистов. Т е где-то материал будет полезен, а где-то не очень. А общая унификация вообще может жить только в вакууме и в реалии весьма вредна. И книги авторитетов не являются исключением.
Вас тоже с праздниками! Данный пример для си-языков, а здесь мы T-SQL рассматриваем. И не смотря на почетную книженцию, в данном примере есть риск, что из цикла можно вообще никогда не выйти. Т е не смотря на авторитет автора и с учетом риска бесконечного зацикливания кода, позволю себе не согласиться. Может раньше так и было можно, а сейчас больше за предсказуемый по выполнению и безопасный код.
Данный пример опасен тем, что можно просто ошибиться и никогда не выйти из цикла
Так что мелочиться то, сразу goto делать вместо всех циклов for и while во всех языках программирования. Удобно для унификации.
Кстати, не напомните номер страницы книги, где упоминается именно о том, что Вы написали?
Жаль, что не смог Вас убедить. Кстати, CTE тоже лучше на лево и направо не раскидываться особенно если таблицы-участницы большие. Но опять же понятие "большие" относительно.
Понимаю, у всех нагрузка большая. Потому я в основном пишу на выходных. Но в любом случае Ваш материал будет интересно изучить, потому надеюсь и буду ждать публикации. Спасибо!
select 1 показывает, что проблем с производительностью СУБД нет. Значит, все остальные рекомендации про оптимизацию являются неверными раз найдены исключения, опровергающие это.
Тем не менее, union тяжеловат сам по себе. И если есть альтернативы, а они есть, то лучше ими воспользоваться.
Оптимизатор умный, но невсегда так будет везти.
Лично я не запрещаю, а рекомендую. Это раз. А во-вторых, пока специалист не обжёгся на конкретном сценарии да ещё и со своим опытом, его очень сложно переубедить. Потому если мои аргументы Вас не переубедили и мы не пересекаемся по проекту, то конечно решение как делать остаётся за Вами и Вашей командой.
Более предсказуемо и невсегда медленнее union.
Обратите внимание, что расписано почему.
или можно сделать как Вы написали выше с CTE, но без CTE, а просто в подзапросе через union all, а снаружи либо group by, либо distinct согласно п.12
Можно добавить отдельными запросами во временную таблицу и потом с этой таблицей сделать либо group by, либо distinct-смотря сколько полей нужно сделать уникальными. Если 1-3 поля-то group by, а если больше, то distinct (про distinct говорится в п.12)