Перечислить придется, причем несколько раз

Ну я уже чисто теоретически интересуюсь, потому что сделал перечислением. Обошелся одним кстати.

Насколько я знаю, такого способа нет. Даже с промежуточной таблицей insert into, потребовал правильного порядка столбцов. Но я подумал, что одна голова хорошо, а 2000 лучше, и спросил у коммьюнити.

подскажите пожалуйста)
у меня есть три значения name1,name2,name3 - вывожу три столбца
как прописать условие так, чтобы если name2 - null, то возвращается name1
если name3 - null, о возвращается name2 (но при этом если name2 тоже null, в таком
случае case ниже возвращает name2 как null, а как сделать так чтобы в таком случае вместо name3 выводило name1)

select name1 as n1,
case  when name2 is not null then name2  else name1 end as n2,
case  when name3 is not null then name3  else name2 end as n3

посмотрите coalesce(n1,n2,n3)

или Case-expression

только динамический запрос, со всеми его недостатками :)

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

или что посоветуете?

Во вью не вызвать процедуру

Максимум функции кажется можно

Join/apply к функции

Ну вот я про тоже,а как сделать тот же функционал с процедурами? Во вью модно использовать временные таблицы и т.д?тоже вроде нет

Пользователь как вызывает вьюхи сейчас? Через что?

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

У пользователя форма, к примеру чеков, форма чеков это вью соединения многих таблиц(, контрагенты, заказы и ТД) они на форме делают к примеру фильтр, чеки от до , либо фильтры , приложение добавляет эти фильтры к вью, делается запрос к базе

Там фильтров, чуть ли не на каждый столбец

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

Типичная проблема динамического поиска. Нужно добавлять рекомпиляцию в выражения, которые часто тупят. OPTION(RECOMPILE). Работу формы лучше переделать на процедуры - пусть они и опираются на те же вьюхи, но гибкости это прибавит существенно. Ну и стоит попробовать QueryStore - эта технология позволяет отслеживать регрессию планов выполнения и указывать, например, какой из известных планов стоит использовать. С 2017 версии есть вплоть до автоматической коррекции планов.

Вот статья академического качества по данной проблематике. Не смотрите, что это про 2008, фундаментально мало что поменялось, чудес не бывает. http://www.sommarskog.se/dyn-search-2008.html