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

Откуда: Кишинёв
Сообщений: 6724
В продолжении темы: Why Doesn't Block Select?

Как немногие знают с 2005-го поменялся принцип доступа инфы для Inserterd / Deleted.
Теперь все триггера, независимо от уровня работы базы требуют генерацию версий строк.

Вот интересная инфа: Understanding Row Versioning-Based Isolation Levels
К примеру:
MSDN
For short-running transactions, a version of a modified row may get cached in the buffer pool without getting written into the disk files of the tempdb database. If the need for the versioned row is short-lived, it will simply get dropped from the buffer pool and may not necessarily incur I/O overhead.
Это я к посту от Гавриленко Сергей Алексеевича: 12260233 Хотя да, это слабо связано.

Как я понимаю, банальное наличие триггера-пустышки на таблице уже приводит к расходам.
Для тестирования необходимо либо положить tempdb на медленный винт или хотя бы логи вместе с ним и урезать максимальную память не сервере. Тест проводить только на большом количестве строк, чтобы версии строк успели упасть на диск.

Отказ от триггеров в пользу ... (чего?) на большой высоко-нагруженной системе может быть заметен.

Ктось почувствовал это? Или у кого есть мысли по поводу этого?
Типа советов при переходе, или смене приоритетов проектирования.
16 май 12, 00:20    [12559924]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
У нас нет ни одного триггера. Ничего, не померли. :)

Хотя, я так понимаю, inserted/deleted в output - все один и тот же механизм. Output используем часто, потому что перевыбирать только что вставленные или проапдейченные записи все равно дольше, хоть они из кеша никуда деться и не успевают.
16 май 12, 01:17    [12559979]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Это я к тому, что отказываться особо некуда, проще двигаться к ндцати шпинделям под tempdb.

Сообщение было отредактировано: 16 май 12, 01:26
16 май 12, 01:20    [12559983]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Гавриленко Сергей Алексеевич
У нас нет ни одного триггера. Ничего, не померли. :)

Хотя, я так понимаю, inserted/deleted в output - все один и тот же механизм. Output используем часто, потому что перевыбирать только что вставленные или проапдейченные записи все равно дольше, хоть они из кеша никуда деться и не успевают.

И чем интересно вызван отказ от триггеров в пользу output?
16 май 12, 01:33    [12559995]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Deff
И чем интересно вызван отказ от триггеров в пользу output?
Такая формулировка не совсем корректна. Мы не написали кучу триггеров, а потом не переписали это все на output'ы. Мы просто сразу не писали триггера. ;)

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

З.Ы. Хотя, изредка, ее приходится повторять при очень нерегламентных обновлениях данных, но это, как правило, с патчами, да еще и тестами покрыто.
16 май 12, 01:44    [12560006]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Гавриленко Сергей Алексеевич
Хотя, я так понимаю, inserted/deleted в output - все один и тот же механизм.
Поразмышлял немного. А на самом деле, с чего бы этот механизм должен быть один?

Есть два крупных различия.

Первое. При выполнении запроса с output четко понятно, какие поля для inserted/deleted нужны. В случае запроса с триггерами, получается, все триггеры надо откомпилировать до выполнения команды (кстати, а когда именно они компилируются/перекомпилируются, до выполнения команды или после?), и по их тексту как-то понять набор полей, к которым идет обращение. Ну или сохранять абсолютно все поля.

Второе. При выполнении запроса с output не нужны никакие дополнительные материализации, в общем-то. Т.е. при модификации каждой записи сервер, во-первых, четко знает, значения каких полей нужны, во-вторых, что с ними делать: или вставлять в таблицу, указанную в том же output (предварительно пропустив через спулы и сортировки , если в таблице-приемнике есть индексы, конечно), или выдать в набор данных клиенту (если таблица-приемник не указана). В случае с триггерами придется все это дело все равно еще как-то материализовать, потому что обращений к inserted/deleted может быть много и в разных триггерах.

В общем, сумбурно несколько, и исключительно размышления. Подтверждения или опровержения надо искать. ;)
16 май 12, 03:19    [12560033]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
To: Гавриленко Сергей Алексеевич, Mnior

Прошу прощения за неграмотность, но я что-то не понял. Что предлагается вместо триггера?
У меня ситуация такая:
с помощью триггера я проверяю данные (достаточно сложная бизнес логика). Если данные соответствуют всем требованиям, то данные сохраняются, если нет, то возвращаю специальный текст ошибки, где пишу в чём проблема. Ну и соответственно данные не сохраняются.
Ну так чем я могу всё это заменить? Не могли бы показать простейший пример кода?
16 май 12, 08:21    [12560204]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
studieren
Ну так чем я могу всё это заменить? Не могли бы показать простейший пример кода?
Можно заменить изменением данных из процедур, при этом для каждого бизнес-действия или для каждой бизнес-сущности пишется своя процедура, в которой и делаются вся эта "достаточно сложная бизнес логика".
16 май 12, 08:57    [12560299]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
step_ks
Member

Откуда:
Сообщений: 936
studieren
To: Гавриленко Сергей Алексеевич, Mnior

Прошу прощения за неграмотность, но я что-то не понял. Что предлагается вместо триггера?

Не бросаться в крайности. У вас какая-то проблема из-за триггеров?

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

Проверкой по месту вставки/модификации. Если таких мест уйма и постоянно появляются новые, которые вы не можете или не хотите контролировать - триггер может быть лучше.
16 май 12, 08:57    [12560300]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
step_ks
Не бросаться в крайности. У вас какая-то проблема из-за триггеров?

Нет, Вы меня не поняли. Я не пытаюсь переделать всё! Просто для решения моей задачи я раньше думал, что это единственное решение (в принципе можно и через check constraint устроить проверку данных, но только более предметное "ругательство" при этом у меня плохо получалось).
Я не ищу альтернативу, а просто хочу узнать другие способы. Вдруг и в правду есть нечто, что лучше триггер. Если это так, то в будущем буду иметь ввиду и по возможности потихоньку буду переделывать свою базу.
16 май 12, 10:17    [12560770]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
alexeyvg
studieren
Ну так чем я могу всё это заменить? Не могли бы показать простейший пример кода?
Можно заменить изменением данных из процедур, при этом для каждого бизнес-действия или для каждой бизнес-сущности пишется своя процедура, в которой и делаются вся эта "достаточно сложная бизнес логика".

Если я правильно Вас понял, то мне нужно создать простую хранимку и там устроить все проверки? Ну и как мне достичь эффекта триггера? Я имею ввиду пользователь что-то внёс / исправил / удалил и тут сразу же зарабатывает хранимка. Как без триггера обойтись?
Хоть маленький пример можете показать?
16 май 12, 10:22    [12560806]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Glory
Member

Откуда:
Сообщений: 104751
studieren
Если я правильно Вас понял, то мне нужно создать простую хранимку и там устроить все проверки? Ну и как мне достичь эффекта триггера? Я имею ввиду пользователь что-то внёс / исправил / удалил и тут сразу же зарабатывает хранимка. Как без триггера обойтись?

Вместо " пользователь что-то внёс / исправил / удалил " должен стоять вызов процедуры
16 май 12, 10:27    [12560847]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
studieren
Я имею ввиду пользователь что-то внёс / исправил / удалил и тут сразу же зарабатывает хранимка.
Да, такое есть, но вот как раз такая хранимка и называется триггером. Триггер - это обычная хранимка, плюс в обработчик событий сиквела записывается, что её нужно вызывать при определённых событиях на сервере. Это как раз тот вариант, который используете вы.
studieren
Как без триггера обойтись?
Хоть маленький пример можете показать?
Второй вариант - пользователям не даётся доступ ни на один объект (таблицу), а даются только права на выполнение процедур. А вот в этих процедурах и делается вся обработка данных.

В принципе в триггерах самих по себе ничего плохого нет, но чем сложнее система и сложнее её логика, тем второй путь (через вызовы процедур) удобнее и проще, как в разработке, так и в поддержке.
16 май 12, 10:43    [12560972]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
alexeyvg
Второй вариант - пользователям не даётся доступ ни на один объект (таблицу), а даются только права на выполнение процедур. А вот в этих процедурах и делается вся обработка данных.

В принципе в триггерах самих по себе ничего плохого нет, но чем сложнее система и сложнее её логика, тем второй путь (через вызовы процедур) удобнее и проще, как в разработке, так и в поддержке.

Ах вот оно что?! :-) А я то подумал изобрели нечто такое ...
По некоторым соображениям такой вариант не всегда меня устраивает. Хотя такой подход тоже имеет смысл.
16 май 12, 10:53    [12561030]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
step_ks
studieren, Не бросаться в крайности. У вас какая-то проблема из-за триггеров?
Вот я кашу то намутил.
Гавриленко Сергей Алексеевич
Потому что у нас несколько тепличные условия и данные в большинстве основных таблиц меняются в одной процедуре.
Не всем так везёт
studieren
Просто для решения моей задачи я раньше думал, что это единственное решение (в принципе можно и через check constraint устроить проверку данных, но только более предметное "ругательство" при этом у меня плохо получалось).
Как раз CHECK является самым что ни на есть лучшим вариантом, просто не для всего его можно написать и не всегда эффективно (сложные проверки с другими таблами).

А вот вам решение для красатулек в ошибках для CHECK-ов. Если чё, могу остальное привести.
--------------------------------------------------------------------------------------------
Гавриленко Сергей Алексеевич
В случае запроса с триггерами, получается, все триггеры надо откомпилировать до выполнения команды (кстати, а когда именно они компилируются/перекомпилируются, до выполнения команды или после?), и по их тексту как-то понять набор полей, к которым идет обращение. Ну или сохранять абсолютно все поля.
Думаю что триггера особо не отличаются от других скриптовых объектов. Поэтому компиляция стайтментов может быть отложена (если я ничего не путаю). На примере триггеров для вьюх видно, что все поля создаются. Если бы они могли регулировать наборы полей, я бы на них молится бы стал. Но ани, *уки, в эту сторону и не смотрят. C точки зрения маркетинга ... ну вы поняли.

Гавриленко Сергей Алексеевич
При выполнении запроса с output не нужны никакие дополнительные материализации, в общем-то. Т.е. при модификации каждой записи сервер, во-первых, четко знает, значения каких полей нужны, во-вторых, что с ними делать: или вставлять в таблицу, указанную в том же output (предварительно пропустив через спулы и сортировки , если в таблице-приемнике есть индексы, конечно), или выдать в набор данных клиенту (если таблица-приемник не указана).
Более того в плане запроса видно, что делается вставка в таблицу, так что да, RowVersion тут не причём.

Есть одно убийственное ограничение, что нельзя ставить CHECK на вставляемую через OUTPUT таблицу, что жутко бесит. И это я никак не могу объяснить.
В плане же также видно что Assert/Update имеет предикат, составленный из выражений этих ограничений. Значит и CHECK работает на ммент вставки/изменения, так откуда это долбаннное ограничение ?
16 май 12, 16:37    [12564376]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mnior
Ктось почувствовал это? Или у кого есть мысли по поводу этого?
Типа советов при переходе, или смене приоритетов проектирования.
Да и на основной вопрос ответа пока не поступило.
17 май 12, 01:10    [12566764]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Up
18 май 12, 01:05    [12573858]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Ок. Понятно, что с RV не сильно приседает сервер. Но надо учитывать при разборе полётов "Тормозит при переходе на 2005/2008".
И 2е - холиварщики про "Триггера vs Процедуры" и т.п. просто сейчас находятся не в берсерек моде.
Но аргумен то, аргумент!
18 май 12, 13:51    [12576842]     Ответить | Цитировать Сообщить модератору
 Re: RV: Триггера vs ...  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
У меня есть обработка длительная. На вставляемой таблице есть триггер, которые считает нарастающий итог по полю.
У меня как руки дойдут: уберу триггер, добавлю код в процедуру обработки. Замерю скорость. О результатах доложу.
19 май 12, 14:12    [12581700]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить