Есть ли способ предотвратить отключение триггеров? - PullRequest
3 голосов
/ 17 июня 2010

У меня есть триггер на столе, который никогда не должен быть отключен. Он выполняет определенные проверки, и были случаи, когда другие разработчики отключали его, чтобы обойти это. Это не очень хорошо, поэтому я хочу иметь возможность отключить отключение триггера только на этой таблице. Это возможно? Если нет, любые предложения, пожалуйста. спасибо.

Временное решение: Судя по пипсовым ответам, предотвратить это невозможно. Может быть, было бы целесообразно получить оповещение. Это хорошая статья, к сожалению, она не работает с EventData. Может быть, в 2008 году это решено: http://www.simple -talk.com / SQL / базы данных управления / DML-триггер-статус-сигналы /

Ответы [ 7 ]

7 голосов
/ 17 июня 2010

У вас нет технической проблемы, у вас есть социальная проблема.

Кто эти "другие разработчики"?

Почему они настраивают триггеры?

Какова их цель?

Что не так с триггером?

Вам следует поговорить с ними и узнать, в чем их проблема.

Не тратьте время на поиск технического "решения",только сделает проблему хуже или сложнее.Найди людей.Поговори с ними.

5 голосов
/ 17 июня 2010

Любое решение, которое вы используете, может быть отключено разработчиками, например, Триггеры DDL

Единственные решения

  • удалить права на отключение триггеров
  • снимать / стрелять / ранить разработчиков, если они не изменятся
3 голосов
/ 17 июня 2010

Разработчики не должны иметь прав администратора на производственную базу данных. Они не должны иметь возможность отключать триггеры, потому что у них не должно быть прав на prod для выполнения каких-либо действий, кроме select.

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

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

Это указывает на то, что сам триггер является проблемой. Перепишите его, чтобы не требовалось обходного пути.

На основании комментария

Добавьте поле триггера перегрузки для ваших данных. Если вы хотите переопределить его, отправьте значение 1, если вставленная таблица имеет значение 1, а затем укажите if, который игнорирует те части триггера, которые вам нужны для этих записей, но затем он продолжается и выполняет другие триггерные операции. В конце сбросьте значение поля переопределения на ноль.

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

Или вообще уберите «иногда мы запускаем это» из триггера и добавьте его в процессы, которые вставляют записи, где вы хотите, чтобы они выполнялись, а не в другие.

2 голосов
/ 17 июня 2010

Я склонен согласиться с комментарием HLGEM. Вы, вероятно, делаете неправильные вещи в триггере, и поэтому люди чувствуют необходимость обойти это. Так что избавься от этого или перепиши это. Я говорю «вероятно», потому что почти все триггеры не нужны, а триггеры - плохое место для размещения кода манипулирования данными. Триггеры, которые применяют бизнес-правила без изменения данных, достаточно разумны. Триггеры, которые на самом деле выполняют ОБНОВЛЕНИЯ, ВСТАВКИ и УДАЛЕНИЯ, как правило, приносят гораздо больше хлопот, чем стоят, и почти всегда могут быть заменены лучшими альтернативами.

2 голосов
/ 17 июня 2010

Нет. Отключение - это операция администратора, поэтому ее нельзя предотвратить. Вы можете проверить, отключены ли триггеры по коду .... но не помешать отключению.

Имеет смысл, даже, например, для разработчиков (во время отладки).

1 голос
/ 17 июня 2010

Может быть Вы можете создать другого пользователя, предоставить возможность выбора / вставки / обновления / удаления в дополнительных таблицах новому пользователю.Или вы можете отозвать доступ к триггерам для вашего пользователя, которому принадлежат таблицы.

0 голосов
/ 17 июня 2010

По возможности используйте ограничения и убедитесь, что им доверяют.

...