[rivera]

Поясню на примере
Задача:
обновить всех мужчин в таблице продавцов (Sales)

Код:

update Sales
Set Gender = 'M'
where LastName like '%ов'

Будет ли запрос выполняться быстрей при такой схеме

Код:

--временная таблица
declare @Rows table (id int)

--выбираем все строки по ключевому полю записи которые будем обновлять:
--id первичный ключ, кластерный индекс в таблице Sales
insert into @Rows (id)
select id from Sales where LastName like '%ов'

--и теперь обновляем все записи, подставляя подзапрос
update Sales
set Set Gender = 'M'
where id in (select id from @Rows)

будет ли последний блок отрабатывает еще менее затратней по времени и ресурсам при такой схеме?

Код:

--обновляем таблицу через комбинацию join
update sl
set Set Gender = 'M'
from Sales as a
join @Rows as b on a.id = b.id

[fomin_]

rivera,
А в чем собственно проблема?
Посмотрите результат выполнения для каждого приведенного случая через execution plan

[rivera]

для каждой таблицы каждый раз он будет разным, в зависимости от размера раблицы и индексов на нее.
мне же инетересна именно методика написания, которая будет универсальна для большинства таблиц.

ну типа, подзапросы всегда работаю быстрее и менее затратны чем join
или
по кластерному индексу всегда быстрей update происходит, нежели по подзапросу с выборкой произволному полю
и т.д.

[Delirium]

where LastName like '%ов' »

Вот такой запрос всегда будет работать медленней, чем условия вида a.id = b.id. Медленней потому, что оператор LIKE при поиске неизвестного количества символов в НАЧАЛЕ не сможет использовать индексацию данных. Поиск вида Like 'иван%' - уже будет быстрее.
В идеале всегда надо обновлять поля, используя ключевые поля (PK и FK), тогда и результат будет почти мгновенным.
Если же необходимо сделать, как в примере, то лучше писать не LIKE, а что то типа

Код:

where lower(Right(LastName, 2)) ='ов'.

Проверьте все варианты на одной и той же таблице и сравните планы выполнения. Результат будет виден сразу.