Люди, ну о чём спор? Приведённый текст - не код запроса, этот текст здесь же на форуме был написан для примера и заключён в скобочки src, просто для наглядности.
Реально там, действительно не один десяток таблиц связывается, и денормализация напрашивалась бы, и вьюхи можно, и временные таблицы можно, а я вообще в Delphi пишу, там ещё чёрта лысого можно, но это не имеет никакого отношения к техническому вопросу использования динамического поля внутри порождающего его select.

Wlr-l, вполне объяснил. Спасибо!
Shakill в доки ткнул. Спасибо!
Другие люди привели варианты обращения к такому полю. Спасибо!

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

Mindrtv,

Не знаю насчет ошибок проектирования, но условия по полям, вычисленным в запросе через CASE это почти гарантированные проблемы с произодительностью в дальнейшем.
В дальнейшем - это про что? Память забивает сразу, или при масштабировании, или что за проблемы?
Ситуация и специфика задач у нас, действительно, позволяют не особо следить за такими вещами (что плохо, конечно). А конкретно тот запрос с условным отбором, на который ещё условия (который здесь и не выкладывался даже) - вообще доступен только для одного пользователя. Я сразу забираю результат запроса на клиент, могу и без условий забирать.
Но для общего развития интересно - именно задание условий на такие поля - плохо? Или вообще конструкция такого условного отбора в динамическое поле - ну вот совсем плохая?

alexeyvgrtvНо говорить о грубых ошибках проектирования не вид проекта вообще, это сильно.+1
Не обязательно будут проблемы с производительностью, ведь это условие может быть, так сказать, "финишным", отсеивающим 5 записей из 10
Не всегда возможно сделать вычисляемое поле, потому что выражение может быть из полей множества таблиц.
Не во всех случаях нужно делать материализроованные вьюхи на каждый запрос, ведь запрос может выполняться редко, да и план может быть не таким плохим.
В общем, нужно видеть весь проект, а не принимать каждый отдельный (и удачный) приём, как обязательный к повторению шаблон проектирования.
Про логику с финишными условиями. У меня по тому динамическому полю отсеиваются всё с пустым полем. То есть интересно то, куда что-то отобралось при условном отборе, и да из кучи таблиц. И отсеется больше, чем останется.
И вот это плохо?
Или когда будет не так плохо с "финишным" условием - когда по нему отсеется большинство записей, или наоборот?