Здравствуйте, _d_m_, Вы писали:
___>А какая разница? Я же сказал — кодогенерация.
Опять по кругу? Приплетать кодогенреацию вместо того чтобы написать 10 строк кода руками?
___>Ах вот она где собака порылась! Ты оказывацо не знаешь как работает триггер. Так вот триггер выполняется ровно один раз на ровно один оператор.
Код триггера в студию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _d_m_, Вы писали:
___>>А какая разница? Я же сказал — кодогенерация.
Z>Опять по кругу? Приплетать кодогенреацию вместо того чтобы написать 10 строк кода руками?
Да что ты нас стращаешь? Каких еще нафиг 10 строк. Проходили — нет проблем. В нашем случае стандартная репликация не подходит. Так что для кодогенерации нарисовал один класс — используются шаблоны с параметрами.
___>>Ах вот она где собака порылась! Ты оказывацо не знаешь как работает триггер. Так вот триггер выполняется ровно один раз на ровно один оператор.
Z>Код триггера в студию.
Тебе надо не код триггера смотреть, а документацию
Например:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER trigger [dbo].[пРепликация_Товары_Удал_ЗамВст] on [dbo].[пРепликация_Товары_Удал]
--# with encryption
instead of insert
as begin
set nocount on;
delete
dbo.Товары
from
dbo.Товары т
inner join
inserted вст
on
т.Код=вст.Код
;
end
Здравствуйте, _d_m_, Вы писали:
___>Да что ты нас стращаешь? Каких еще нафиг 10 строк. Проходили — нет проблем. В нашем случае стандартная репликация не подходит. Так что для кодогенерации нарисовал один класс — используются шаблоны с параметрами.
Какая стандартная репликация? Я обсуждаю вопрос как оптимальнее удалить записи из одной БД, если мы имеем ридер читающий их ключи из другой БД.
___>___>SET ANSI_NULLS ON
___>GO
___>SET QUOTED_IDENTIFIER ON
___>GO
___>ALTER trigger [dbo].[пРепликация_Товары_Удал_ЗамВст] on [dbo].[пРепликация_Товары_Удал]
___>--# with encryption
___>instead of insert
___>as begin
___> set nocount on;
___> delete
___> dbo.Товары
___> from
___> dbo.Товары т
___> inner join
___> inserted вст
___> on
___> т.Код=вст.Код
___> ;
___>end
___>
Ага, statement level trigger.
Тут еще лучше, сначала мы вставим данные куда-то. Операция недешевая, мы либо выкинем из памяти нужные данные, либо вообще не влезем в память и будем скидывать вставляемые данные на диск, а потом читать их оттуда. Очень здорово. Надеюсь вы понимаете, что это решение не масштабируется. Оно жрет ограниченные ресурсы O(N).
Это все ради того, чтобы не генерировать delete from?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Здравствуйте, Ziaw, Вы писали:
Z>Ага, statement level trigger.
Z>Тут еще лучше, сначала мы вставим данные куда-то. Операция недешевая, мы либо выкинем из памяти нужные данные, либо вообще не влезем в память и будем скидывать вставляемые данные на диск, а потом читать их оттуда. Очень здорово. Надеюсь вы понимаете, что это решение не масштабируется. Оно жрет ограниченные ресурсы O(N).
Прекрасно масштабируется. Ты когда говоришь про дешевезну чего-либо, не забывай добавлять по сравнению с чем.
Так и с чем мы сравниваем? Со строкой с параметрами?
Если даже забыть про ограничения на размер батча. Даже если забыть про необходимость затрат ресурсов на генерацию на клиенте. Этот оператор должен ведь придти на сервер, он должен его разместить в памяти, разобрать — операция недешевая.
Z>Это все ради того, чтобы не генерировать delete from?
Заааачеееем? Нафиг мне его генерировать. Есть решение проще и легковесней — я про него как раз и говорю. Если следовать твоей логике — то и поддержка версионных уровней изоляций "не масштабируется и жрет ограниченные ресурсы".
PS: Кстати, удаление как и обновление может проводится по частям, например по 50 тысяч строк. Оператор TOP рулит.
