Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Всем, привет!


Согласно бизнес логике нужно обновить view-er

В #tbl несколько сотен строк
в vwr несколько десятков миллионов строк.
Кол-во строк которых нужно обновить в vwr совпадает с кол-во строк в #tbl

Написал такой скрипт, но он не работает из за
UPDATE is not allowed because the statement updates view "vwr" which participates in a join and has an INSTEAD OF UPDATE trigger.

Триггер не работает в случае JOIN

UPDATE a
SET record = 'S'
FROM #tbl INNER JOIN vwr a b ON a.id = b.id and a.table_id = b.table_id
WHERE <условие>

Переделал скрипт на

UPDATE a
SET record = 'S'
FROM vwr
WHERE EXISTS(SELECT * FROM #tbl b WHERE a.id = b.id and a.table_id = b.table_id AND <условие> )

Правильно ли я понимаю, что в этом случае UPDATE будет сканировать все строки vwr (десятки миллионов) и каждую из них сопоставлять с условием EXISTS ?
12 окт 12, 12:13    [13307536]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Testor1
Правильно ли я понимаю, что в этом случае UPDATE будет сканировать все строки vwr (десятки миллионов) и каждую из них сопоставлять с условием EXISTS ?
План посмотрите, чо гадать-то?
12 окт 12, 12:17    [13307576]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Testor1
Согласно бизнес логике нужно обновить view-er
FacePalm.jpg
Люди, вы сами понимаете что говорите?!
В бизнес логике нет технический понятий, там чистая абстракции предметной области.
А вот БД, таблица, SQL запрос - это техническое решение.
12 окт 12, 13:26    [13308179]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Testor1
Триггер не работает в случае JOIN
Давно пора MERGE освоить.
CREATE TABLE [dbo].[Test] (
	 ID	Int		PRIMARY KEY
	,Record	VarChar(1)	NOT NULL
)
GO
CREATE VIEW [dbo].[vwTest] AS
SELECT	 Convert(SmallInt,1)	AS TableID
	,T.ID
	,T.Record
FROM	dbo.Test	T
GO
CREATE TRIGGER [trTestUpdate] ON [dbo].[vwTest]
INSTEAD OF UPDATE AS BEGIN
	DECLARE @RowCount BigInt = @@RowCount
	SET NOCOUNT ON

	UPDATE	T
	SET	Record	= I.Record
	FROM	     Inserted	I
		JOIN dbo.Test	T ON T.ID = I.ID
	WHERE	I.TableID = 1
	-- Check RowCount ...
END
GO
DECLARE	@Test TABLE (
	 TableID	SmallInt
	,ID		Int
	 PRIMARY KEY (TableID,ID)
	,Record		VarChar(1)	NOT NULL
)
;---------------------------------------
MERGE	dbo.vwTest	D
USING	@Test		S ON D.TableID	= S.TableID
			 AND D.ID	= S.ID
WHEN	MATCHED	-- AND <Условие>
THEN	UPDATE
SET	Record	= S.Record
;
12 окт 12, 13:37    [13308265]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Mnior
Testor1
Триггер не работает в случае JOIN
Давно пора MERGE освоить.
CREATE TABLE [dbo].[Test] (
	 ID	Int		PRIMARY KEY
	,Record	VarChar(1)	NOT NULL
)
GO
CREATE VIEW [dbo].[vwTest] AS
SELECT	 Convert(SmallInt,1)	AS TableID
	,T.ID
	,T.Record
FROM	dbo.Test	T
GO
CREATE TRIGGER [trTestUpdate] ON [dbo].[vwTest]
INSTEAD OF UPDATE AS BEGIN
	DECLARE @RowCount BigInt = @@RowCount
	SET NOCOUNT ON

	UPDATE	T
	SET	Record	= I.Record
	FROM	     Inserted	I
		JOIN dbo.Test	T ON T.ID = I.ID
	WHERE	I.TableID = 1
	-- Check RowCount ...
END
GO
DECLARE	@Test TABLE (
	 TableID	SmallInt
	,ID		Int
	 PRIMARY KEY (TableID,ID)
	,Record		VarChar(1)	NOT NULL
)
;---------------------------------------
MERGE	dbo.vwTest	D
USING	@Test		S ON D.TableID	= S.TableID
			 AND D.ID	= S.ID
WHEN	MATCHED	-- AND <Условие>
THEN	UPDATE
SET	Record	= S.Record
;



Да. VWR - нужно обновлять согласно бизнес логике. Не в плане, что бизнес требует vwr обновить, а в том, что обновления производятся согласно какой-то логике.

Как обновлять данные это технический вопрос.

Сейчас попробую MERGE. Я его использую, но не знал, что он помочь в моем случае.

По поводу vwr - он состоит из нескольких таблиц объединены UNION. По этой причине и использовал триггер.

И вопрос - почему MERGE должен работать быстрее, чем подзапрос ? Я не спорю, а хочу понять на конкретном примере.
12 окт 12, 14:07    [13308461]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Mnior
Testor1
Триггер не работает в случае JOIN
Давно пора MERGE освоить.
CREATE TABLE [dbo].[Test] (
	 ID	Int		PRIMARY KEY
	,Record	VarChar(1)	NOT NULL
)
GO
CREATE VIEW [dbo].[vwTest] AS
SELECT	 Convert(SmallInt,1)	AS TableID
	,T.ID
	,T.Record
FROM	dbo.Test	T
GO
CREATE TRIGGER [trTestUpdate] ON [dbo].[vwTest]
INSTEAD OF UPDATE AS BEGIN
	DECLARE @RowCount BigInt = @@RowCount
	SET NOCOUNT ON

	UPDATE	T
	SET	Record	= I.Record
	FROM	     Inserted	I
		JOIN dbo.Test	T ON T.ID = I.ID
	WHERE	I.TableID = 1
	-- Check RowCount ...
END
GO
DECLARE	@Test TABLE (
	 TableID	SmallInt
	,ID		Int
	 PRIMARY KEY (TableID,ID)
	,Record		VarChar(1)	NOT NULL
)
;---------------------------------------
MERGE	dbo.vwTest	D
USING	@Test		S ON D.TableID	= S.TableID
			 AND D.ID	= S.ID
WHEN	MATCHED	-- AND <Условие>
THEN	UPDATE
SET	Record	= S.Record
;
Mnior! Ничего не понимаю! Мы ж по этому поводу столько всего когда-то выяснили.
Какой-такой @@ROWCOUNT, если хотим использовать в MERGE?!
Хотите сказать, что сейчас там только UPDATE?
Сиюминутность решения - это признак говнокода, не правда ли?
Правда, непонятно, зачем там вообще @@ROWCOUNT
12 окт 12, 14:29    [13308629]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
iap
Мы ж по этому поводу столько всего когда-то выяснили.
Видимо забыл, напомните.
iap
непонятно, зачем там вообще @@ROWCOUNT
Ну TableID как бэ намекает. Может я и не угадал.
А для чего же view то, соединить несколько табель.
12 окт 12, 16:35    [13309693]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Mnior,

Есть несколько исторических таблиц.
Необходимо отмечать "использованные" записи в этих таблицах согласно определенной логике.

Чтобы не создавать N update-ов для каждой таблицы, я создал один Viewer и работаю через него.

Возможно не самое лучшее решение с точки зрения производительности.
12 окт 12, 17:09    [13309907]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Testor1, с вами вроде разобрались, вопрос был iap

Смысл в том, что само по себе наличие команды MERGE запрещает использование @@RowCount.
Ибо он даёт значение для всей команды MERGE, а не только для UPDATE-нутых данных.
Поэтому лучше работать только с псевдо-таблицами Inserted / Deleted.

Но если определён только один триггер на UPDATE, и INSERT/DELETE запрещён, то халтура прокатит.

Так что уберите всякое упоминание RowCount из моего скрипта.
Надо по другому контролить данные.

Там много проблем, ибо между запросом данных для UPDATE и запуском триггера могут проскочить изменения.
Поэтому на VIEW часто ставят режим RepeatableRead.
А далее запретить менять колонки TableID и ID

+ Код
CREATE TABLE [dbo].[Test] (
	 ID	Int		PRIMARY KEY
	,Record	VarChar(1)	NOT NULL
)
GO
CREATE VIEW [dbo].[vwTest] AS
SELECT	 Convert(SmallInt,1)	AS TableID
	,T.ID
	,T.Record
FROM	dbo.Test	T
GO
CREATE TRIGGER [trTestUpdate] ON [dbo].[vwTest]
INSTEAD OF UPDATE AS BEGIN
	SET NOCOUNT ON

	IF Update(TableID)
	OR Update(ID)
	BEGIN
		ROLLBACK
		RAISERROR('Нельзя менять ключевую информацию',18,1)
		RETURN
	END

	UPDATE	T
	SET	Record	= I.Record
	FROM	     Inserted	I
		JOIN dbo.Test	T ON T.ID = I.ID
	WHERE	I.TableID = 1

	-- ... Остальные таблы
END
GO
DECLARE	@Test TABLE (
	 TableID	SmallInt
	,ID		Int
	 PRIMARY KEY (TableID,ID)
	,Record		VarChar(1)	NOT NULL
)
;---------------------------------------
MERGE	dbo.vwTest
WITH (RepeatableRead)	D
USING	@Test		S ON D.TableID	= S.TableID
			 AND D.ID	= S.ID
WHEN	MATCHED	-- AND <Условие>
THEN	UPDATE
SET	Record	= S.Record
;---------------------------------------
DROP VIEW [dbo].[vwTest]
DROP TABLE [dbo].[Test]
12 окт 12, 17:46    [13310211]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Как определить уровень изоляции транзакций для объекта?
12 окт 12, 17:48    [13310230]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Mnior,

прошу прощения, что не ответил - я всё это время домой с работы ехал!
Но, кажется, всё разъяснилось?
В данном случае, когда один только UPDATE, может, его и хватило бы (без MERGE)?
12 окт 12, 18:20    [13310442]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mnior
Как определить уровень изоляции транзакций для объекта?
Up
12 окт 12, 18:52    [13310652]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Mnior
Mnior
Как определить уровень изоляции транзакций для объекта?
Up

Тролите ?
1. DBCC USEROPTIONS

2.
SELECT CASE transaction_isolation_level 
WHEN 0 THEN 'Unspecified' 
WHEN 1 THEN 'ReadUncomitted' 
WHEN 2 THEN 'Readcomitted' 
WHEN 3 THEN 'Repeatable' 
WHEN 4 THEN 'Serializable' 
WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL 
FROM sys.dm_exec_sessions 
where session_id =@@spid
12 окт 12, 20:28    [13311102]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Maxx,

но еснно ето все для сесии - что автор имел ввиду для обьекта - ХЗ
12 окт 12, 20:28    [13311104]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mnior
Как определить уровень изоляции транзакций для объекта?
Ну т.е. могу ли я определить, что изменение вьюхи было вызвано в нужной изоляции?
Да, согласен тема отдельного топика. Но возможно вопрос лишён смысла.
12 окт 12, 20:40    [13311172]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Maxx - большой сенкс.
Maxx
Тролите
Скорее подчёркиваю упущение создателей продукта.
Maxx
что автор имел ввиду для обьекта - ХЗ
dbo.vwTest WITH (RepeatableRead)
Level он как значение по умолчанию, а по объектно оно от самого запроса зависит.
12 окт 12, 20:54    [13311257]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
ALTER TRIGGER [dbo].[trg_vwr]
   ON  [dbo].[vwr]
   INSTEAD OF UPDATE

AS 
BEGIN
	SET NOCOUNT ON;

	DECLARE @id INT,
			@subid VARCHAR(16),
			@datetime DATETIME, 
			@balinf VARCHAR(2000), 
			@request_id INT,  
			@table_id SMALLINT;

	DECLARE cursor_local CURSOR LOCAL FOR 
	SELECT id, subid, [datetime], balinf, request_id, table_id
	FROM INSERTED 

	BEGIN TRY 
		
		OPEN cursor_local;
		
		FETCH cursor_local INTO @id, @subid, @datetime, @balinf, @request_id, @table_id; 
		
		WHILE(@@FETCH_STATUS = 0)
		BEGIN 
		
			IF(@table_id = 1)
				UPDATE tb_table1 
				SET subid = @subid,
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;	
			ELSE IF(@table_id = 2)
				UPDATE tb_table2  
				SET ctn = @subid,  
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;	
			ELSE IF(@table_id = 3)
				UPDATE tb_table3 
				SET subid = @subid,  
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;					
			ELSE IF(@table_id = 4)
				UPDATE tb_table4 
				SET subid = @subid,  
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;	
			ELSE IF(@table_id = 5)
				UPDATE tb_table5
				SET subid = @subid,  
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;	
			ELSE IF(@table_id = 6)
				UPDATE tb_table6
				SET subid = @subid,  
					dt = @datetime, 
					balinf = @balinf,
					request_id = @request_id
				WHERE id = @id;	
						
			FETCH cursor_local INTO @id, @subid, @datetime, @balinf, @request_id, @table_id;
		END 
		
		CLOSE cursor_local;
		DEALLOCATE cursor_local; 
				
	END TRY 
	BEGIN CATCH 
	
		EXEC usp_RethrowError
		
	END CATCH 

END


Я использую курсор в триггере.

И все же не получил ответа, будет ли merge быстрее чем update с подзапросом?

Я оставляю уровень изоляции по умолчанию.
12 окт 12, 21:31    [13311458]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Testor1
1. Я использую курсор в триггере.
2. будет ли merge быстрее чем update с подзапросом?
3. Я оставляю уровень изоляции по умолчанию.
Тройной FacePalm.jpg

Это не лечится.
13 окт 12, 00:44    [13312222]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Mnior,

Поясни, что не так.
13 окт 12, 09:52    [13312575]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
1. Забудьте о таком недоразумении как курсор. Он нигде не нужен.
Если вы думаете что где-то он необходим или лучше - вы ошибаетесь - нигде.
2. Не надо юзать try-catch где не попадя. Тем более там где нет обработки, как здесь.
За такое вам оторвут руки в любом языке программирования.
И в никаких триггерах он не нужен вааще. Только в процедурах/скриптах ну и на клиенте (ва том языке).
3. MERGE и UPDATE это разная форма записи, но работают для вашего случая идентично. Посмотрите планы запросов. И вообще, не может быть жёсткой ассоциации в языках высокого уровня между формой записи и реальными действиями.
4. Вы совершенно проигнорировали мой пост 13310211
Для триггеров INSTEAD OF есть проблема:
Mnior
между запросом данных для изменения и запуском триггера могут проскочить параллельные изменения
Поэтому на VIEW при их изменении часто ставят режим RepeatableRead или выше.
MERGE	dbo.vwTest
WITH (RepeatableRead)	D
USING	@Test		S ON D.TableID	= S.TableID
			 AND D.ID	= S.ID
WHEN	MATCHED	-- AND <Условие>
THEN	UPDATE
SET	Record	= S.Record
А всё потому что вы не догоняете смысл слов INSTEAD OF.
Вот вы мне скажите, что это означает? Давайте.
5. Не забывайте писать схемы, никогда. Это банально меленее. Если схема не указана, то скуль откладывает компиляцию на потом и делает её при каждом запуске, пытаясь найти таблицы с таким же именем (но другой схемой), согласно логической цепочке.

Ваш код должен отражать только бизнес логику, не должно быть ни одного лишнего символа (или отсутствия) не по делу.
Переменные зло, цикли зло ... курсоры - исчадье ада.

+ Переделанный триггер
ALTER TRIGGER [dbo].[trg_vwr] ON [dbo].[vwr]
INSTEAD OF UPDATE AS BEGIN
	SET NOCOUNT ON;

	IF Update(TableID)
	OR Update(ID)
	BEGIN
		ROLLBACK
		RAISERROR('Нельзя менять ключевую информацию',18,1)
		RETURN
	END

	UPDATE	T
	SET	 SubID		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table1	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 1

	UPDATE	T
	SET	 ctn		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table2 	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 2

	UPDATE	T
	SET	 SubID		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table3	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 3

	UPDATE	T
	SET	 SubID		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table4	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 4

	UPDATE	T
	SET	 SubID		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table5	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 5

	UPDATE	T
	SET	 SubID		= I.SubID
		,DT		= I.DateTime
		,BalInf		= I.BalInf
		,Request_ID	= I.Request_ID
	FROM	     Inserted		I
		JOIN dbo.tb_table6	T ON T.ID = I.ID
	WHERE	I.Table_ID	= 6
END
GO
13 окт 12, 13:10    [13312945]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Спасибо за инфо. Плиз, без эмоций. Ценю и уважаю чужой опыт и знания. Я не проходил обучение по SQL. Все знания накоплены за счет практики

1. Я в редких случаях использую курсоры. Одна из причин, по которым я использовал курсор в данном случае - уменьшить кол-во операций (выборок из INSERTED) для обновления данных.

Допустим был дан запрос на обновление 100 строк во view.
В этом случае курсор сработает 100 раз и будет выполнен запрос на обновление 6 таблиц (будет обновляться только нужная таблица).

В вашем примере для всех 6 таблиц будут 100 раз выполняться update. А если обновляется только одна таблица, то зачем в холостую делать выборку для остальных 5 таблиц? Есть обоснованные аргументы?

2. TRY CATCH - это привычка. Я использую эту конструкцию как альтернативу IF @@ERROR. Кстати try catch - нагружает дополнительно процессор ?

3. Были похожие мысли

4. INSTEAD OF. Это значит, что триггер срабатывает перед фактическим изменением данных в таблице. Вместо обновляемых данных, я могу передавать другие значения. Я часто использую эту конструкцию.

В моей задаче исторические данные обновляются дважды Job-ом и в приведенной последовательности
1) загрузка исторических данных раз в сутки
2) маркирование записей, которые были использованы в расчете.

Имеет ли смысл использовать RepeatableRead в моем случае?

5. Не всегда получается отказаться от переменных. Очень хотел бы получить реальный опыт разработки от профи со стажем на конкретном проекте.
13 окт 12, 17:58    [13313686]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
Допустим был дан запрос на обновление 100 строк во view.
В этом случае курсор сработает 100 раз и будет выполнен запрос на обновление 6 таблиц (будет обновляться только нужная таблица).

В вашем примере для всех 6 таблиц будут 100 раз выполняться update. А если обновляется только одна таблица, то зачем в холостую делать выборку для остальных 5 таблиц? Есть обоснованные аргументы?

Вы по всей видимости думаете, что триггер срабатывает для каждой записи что ли ?
13 окт 12, 18:24    [13313733]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Допустим был дан запрос на обновление 100 строк во view.
В этом случае курсор сработает 100 раз и будет выполнен запрос на обновление 6 таблиц (будет обновляться только нужная таблица).

В вашем примере для всех 6 таблиц будут 100 раз выполняться update. А если обновляется только одна таблица, то зачем в холостую делать выборку для остальных 5 таблиц? Есть обоснованные аргументы?

Вы по всей видимости думаете, что триггер срабатывает для каждой записи что ли ?


	UPDATE	T
	SET	Record	= I.Record
	FROM	     Inserted	I
		JOIN dbo.Test	T ON T.ID = I.ID
	WHERE	I.TableID = 1

	-- ... Остальные таблы


В моем понимании триггер срабатывает для каждой обновляемой строки во View.

Если добавить остальные 5 таблиц, в примере как предлагал Mnior, то для 6 таблиц должна выполнится выборка из Inserted, чтобы выбрать нужные записи для обновления. А выборка из Inserted - это сканирование 100 записей в этой таблице (цикл от 1 до 100 с IF).
13 окт 12, 18:35    [13313770]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
В моем понимании триггер срабатывает для каждой обновляемой строки во View.

Триггер страбатывает 1 раз. Потому что это триггер для события.
13 окт 12, 18:50    [13313819]     Ответить | Цитировать Сообщить модератору
 Re: Производительность обновления view с подзапросом  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
В моем понимании триггер срабатывает для каждой обновляемой строки во View.

Триггер страбатывает 1 раз. Потому что это триггер для события.


Сорри. Действительно триггер сработает 1 раз, но в таблице Inserted будет 100 записей. А в остальном логика та же.

для каждой из таблицы будет делаться выборка из Inserted (100 записей), с целью определения какие записи обновлять.
13 окт 12, 19:26    [13313963]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить