powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Триггер
16 сообщений из 91, страница 4 из 4
Триггер
    #37844746
Xordal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичА с какого перепугу он не должен отрабатывать?
iapЕщё как!
Запустите мой пример и убедитесь.
Или соорудите свой для DELETE MyTable WHERE 2*2=5;
Спасибо! Не разбирался еще, предполагал что For Delete будет отрабатывать только если записи были реально удалены. В триггерах всегда использовал джоины на обе таблицы (inserted, deleted) и по ним определял, реально ли запись была удалена.
...
Рейтинг: 0 / 0
Триггер
    #37844784
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDminvmпропущено...
Даже тогда, когда проверка этой самой реальности дороже самих изменений?А Вы можете без реальных данных, статистик и тп на пальцах доказать, что проверка этой самой реальности дороже самих изменений? Вот и я не могу доказать обратное. Смысл продолжать? :)Из этого следует, что такие проверки нужно безусловно использовать?
...
Рейтинг: 0 / 0
Триггер
    #37844803
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invmRubinDmпропущено...
А Вы можете без реальных данных, статистик и тп на пальцах доказать, что проверка этой самой реальности дороже самих изменений? Вот и я не могу доказать обратное. Смысл продолжать? :)Из этого следует, что такие проверки нужно безусловно использовать?Нет, я не утверждал, что всегда надо делать именно так. Не только Вы за здравый смысл. Но в качестве примера я счел нужным сделать именно так.
...
Рейтинг: 0 / 0
Триггер
    #37844821
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDminvmпропущено...
Даже тогда, когда проверка этой самой реальности дороже самих изменений?А Вы можете без реальных данных, статистик и тп на пальцах доказать, что проверка этой самой реальности дороже самих изменений? Вот и я не могу доказать обратное. Смысл продолжать? :)А вы можете привести код для случая 12739046 ? Вот тогда и доказывать будем.
...
Рейтинг: 0 / 0
Триггер
    #37844892
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичRubinDmпропущено...
Таблицы модифицировать надо. Но делать это надо только в тех случаях, когда это реально необходимо.С нетерпением жду пример кода, который будет определять, надо ли реально апдейтить 50 полей в таблице по 50 переменным, или вообще по временной таблице.Я не понимаю поставленную Вами задачу.
...
Рейтинг: 0 / 0
Триггер
    #37844917
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDmГавриленко Сергей Алексеевичпропущено...
С нетерпением жду пример кода, который будет определять, надо ли реально апдейтить 50 полей в таблице по 50 переменным, или вообще по временной таблице.Я не понимаю поставленную Вами задачу.Печально.
...
Рейтинг: 0 / 0
Триггер
    #37844943
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичRubinDmпропущено...
Я не понимаю поставленную Вами задачу.Печально.Не то слово. Вы можете поставить задачу иначе, более конкретно?
...
Рейтинг: 0 / 0
Триггер
    #37844966
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDmГавриленко Сергей Алексеевичпропущено...
Печально.Не то слово. Вы можете поставить задачу иначе, более конкретно?Не вижу смысла.
...
Рейтинг: 0 / 0
Триггер
    #37844995
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичRubinDmпропущено...Не то слово. Вы можете поставить задачу иначе, более конкретно?Не вижу смысла.Это уже флуд, уважаемый. На том и остановимся.
...
Рейтинг: 0 / 0
Триггер
    #37845026
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDmГавриленко Сергей Алексеевичпропущено...
Не вижу смысла.Это уже флуд, уважаемый. На том и остановимся.

представьте на таблице триггер after update, обновляющий вторую таблицу с такой же структурой по тем же значениям ключа. при условии что полей данных много. вы правда будете проверять "задетость" столбцов и конструировать в соответствии с этим команду update в теле триггера?
...
Рейтинг: 0 / 0
Триггер
    #37845128
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shakillпредставьте на таблице триггер after update, обновляющий вторую таблицу с такой же структурой по тем же значениям ключа. при условии что полей данных много. вы правда будете проверять "задетость" столбцов и конструировать в соответствии с этим команду update в теле триггера?
Зачем 1в1 синхронизировать таблицы с таким количеством полей? Ну да ладно. Видимо речь о задаче в стиле "history maintenance". Задачи такого рода делятся на два шаблона (с вариациями):
1) таблица с историей зеркально повторяет оригинальную таблицу. в данном случае ответ - конечно нет, в тригере я ничего не буду выдумывать, буду тупо insert'ить в хистори значения всех полей измененных записей оригинальной таблицы.
2) таблица с историей содержит колонки: ID записи в оригинальной таблице, Key - ключ измененного поля, OldVal & NewVal - старое и новое значение измененного поля соответственно. + дата изменения, identity изменения... В данном случае ответ - конечно да, я буду искать измененные поля с помощью функции update(FieldName) с тем, чтобы не делать холостые инсерты в хистори на каждое неизмененное поле.
...
Рейтинг: 0 / 0
Триггер
    #37845331
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наблюдается массивная перебежка стаи гуру. Все растоптаны.

iapА в общем случае большинство клиентов не заморачиваются определением того,
какие поля им надо перечислить в SET, а какие нет.
Чаще всего перечисляются все, просто некоторые остаются с теми же значениями.
Факт наличия поля в списке SET сам по себе ни о чём не говорит.Ну можно и поспорить. Зависит от клиента. Если мне не изменяет память Entity Framework кажись "оптимизит" в зависимости от логики. Про частные случаи можно и не говорить.

iapПриведёт к удивительным результатам в MERGE!
Я вот именно поэтому потихоньку меняю проверку @@ROWCOUNT на EXISTSАга, значит вы активно юзаете MERGE (иначе никакого профита в переписывании нет).
Но то что вы это упомянули - очень правильно.

Гавриленко Сергей АлексеевичС нетерпением жду пример кода, который будет определять, надо ли реально апдейтить 50 полей в таблице по 50 переменным, или вообще по временной таблице.Это попытка доказать несостоятельность подхода в общем случае, на основании частного?
Хомо сапиенс отличается от машины тем, что иногда делает ошибки когда знает что они глупые.

GloryА что виртуальные таблицы уже готовые лежат в памяти как только триггер сработал ?
По сравнению с доступом к системной функции @@ROWCOUNT.С 2005 кое-что поменялось (RowVersioning). Хрен его знает стало лучше или нет. Во всяком случае теперь подымает не из логов (если данных жуть). А tempdb вынужденно ускоряется.
А с другой стороны нужна любая строка, не важно первая или нет (любая в памяти) - хотя неизвестны доступные стратегии доступа для оных виртуальных таблиц.

PS: Эх ... <мечтает о декларативных триггерах>
...
Рейтинг: 0 / 0
Триггер
    #37845591
PVC
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVC
Гость
RubinDmShakillпредставьте на таблице триггер after update, обновляющий вторую таблицу с такой же структурой по тем же значениям ключа. при условии что полей данных много. вы правда будете проверять "задетость" столбцов и конструировать в соответствии с этим команду update в теле триггера?
Зачем 1в1 синхронизировать таблицы с таким количеством полей? Ну да ладно. Видимо речь о задаче в стиле "history maintenance". Задачи такого рода делятся на два шаблона (с вариациями):
1) таблица с историей зеркально повторяет оригинальную таблицу. в данном случае ответ - конечно нет, в тригере я ничего не буду выдумывать, буду тупо insert'ить в хистори значения всех полей измененных записей оригинальной таблицы.
2) таблица с историей содержит колонки: ID записи в оригинальной таблице, Key - ключ измененного поля, OldVal & NewVal - старое и новое значение измененного поля соответственно. + дата изменения, identity изменения... В данном случае ответ - конечно да, я буду искать измененные поля с помощью функции update(FieldName) с тем, чтобы не делать холостые инсерты в хистори на каждое неизмененное поле.

гораздо проще и логичнее во втором варианте воспользоваться UNPIVOT с фильтром на несовпадение значений.
50 if update() в триггере - неэстетично
ИМХО
...
Рейтинг: 0 / 0
Триггер
    #37845812
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RubinDmalexeyvg... В данном случае защита уже есть, её делать не нужно - защитой будет проверка IF UPDATE().и её рекомендовали убрать :)Чтож, кто то рекомендовал, но можно и оставить, я же писал именно про такой вариант. Зависит от конкретного случая - часто ли будут (и будут ли вообще) апдэйты других полей по отдельности.

iapRubinDmпропущено...
и её рекомендовали убрать :)Разумеется.
А роль этой защиты может играть проверка различий значений полей в inserted и deleted в кляузе WHERE, например.Нет, защиты тогда не будет - независимо от проверки различий значений полей в inserted и deleted в кляузе WHERE, команда UPDATE сработает (на нулевое количество записей) и триггер запустится ещё раз (и так бесконечно, то есть 32 раза до появления ошибки).
RubinDmalexeyvgпропущено...
Это всего лишь в 2 раза увеличивает время выполнения триггера, если записи обновляются, и не влияет на скорость, если записей нет.Растолкуйте, каким именно образом данный способ увеличивает время выполнения тригера в 2 раза?Ну как, 2 запроса вместо одного.

Да, наверное, не в 2 раза, так как update тяжелее чем select, но я уж не буду точен до наносекунд :-)
...
Рейтинг: 0 / 0
Триггер
    #37845854
iap
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgНет, защиты тогда не будет - независимо от проверки различий значений полей в inserted и deleted в кляузе WHERE, команда UPDATE сработает (на нулевое количество записей) и триггер запустится ещё раз (и так бесконечно, то есть 32 раза до появления ошибки).Ну, 32 - это не "бесконечно"
Дык ведь если в начале триггера есть проверка типа IF EXISTS(SELECT * FROM deleted), то никакого зацикливания не будет.
...
Рейтинг: 0 / 0
Триггер
    #37846375
RubinDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVCгораздо проще и логичнее во втором варианте воспользоваться UNPIVOT с фильтром на несовпадение значений.
50 if update() в триггере - неэстетично
ИМХОсогласен, можно и так.
...
Рейтинг: 0 / 0
16 сообщений из 91, страница 4 из 4
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Триггер
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]