Триггеры базы данных

Ответ 1

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

Том Ките, вице-президент Oracle указал, что он предпочел бы удалить триггеры как функцию базы данных Oracle из-за их частой роли в ошибках. Он знает, что это просто сон, и триггеры здесь, чтобы остаться, но если бы он мог удалить триггеры из Oracle, он (вместе с предложением WHEN OTHERS и автономными транзакциями).

Можно ли использовать триггеры правильно? Совершенно верно.

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

Ответ 2

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

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

Недостатком триггеров является то, что любое действие может вызывать их; это также сила - никто не собирается испортить целостность системы через некомпетентность.

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

Что касается сокращения объема работы: базы данных потрясающе эффективны, когда им не приходится иметь дело с внешним миром; вы действительно удивитесь, насколько даже переключение процесса ухудшает производительность. Это еще один недостаток хранимых процедур: вместо дюжины звонков в базу данных (и все связанные с ней круглые поездки), там один.

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

Бизнес-логика должна идти куда-то, и существует множество подразумеваемых правил домена, встроенных в дизайн базы данных - отношения, ограничения и т.д. - это попытка кодирования бизнес-правил, говоря, например, что пользователь может иметь только один пароль. Учитывая, что вы начали перетаскивать бизнес-правила на сервер базы данных, имея эти отношения и т.д., Где вы рисуете линию? Когда база данных отказывается от ответственности за целостность данных и начинает доверять вызывающим приложениям и пользователям базы данных, чтобы понять это правильно? Хранимые процедуры с этими встроенными в них правилами могут подтолкнуть большую политическую власть в руки администраторов баз данных. Это сводится к тому, сколько уровней будет существовать в вашей n-уровневой архитектуре; если есть презентация, бизнес и уровень данных, где лежит разделение между бизнесом и данными? Что добавляет значение бизнес-уровня? Будете ли вы запускать бизнес-уровень на сервере базы данных в качестве хранимых процедур?

Да, я думаю, что необходимость обхода триггера означает, что вы "делаете это неправильно"; в этом случае триггер не для вас.

Ответ 3

Я работаю с веб-приложениями и winforms приложениями в С# и я HATE триггерами со страстью. Я никогда не сталкивался с ситуацией, когда я мог бы оправдать использование триггера для перемещения этой логики в бизнес-уровень приложения и репликации там триггерной логики.

Я не делаю никакой работы типа DTS или что-то в этом роде, поэтому для использования триггера могут быть некоторые варианты использования, но если кто-либо из моих команд говорит, что они могут захотеть использовать триггер, они лучше подготовили их аргументы хорошо, потому что я отказываюсь стоять и добавлять триггеры в любую базу данных, над которой я работаю.

Некоторые причины, по которым мне не нравятся триггеры:

• Они перемещают логику в базу данных. Как только вы начнете это делать, вы просите мир боли, потому что вы теряете свою отладку, свою безопасность времени компиляции, свой логический поток. Все это вниз.
• Логика, которую они реализуют, не легко доступна никому.
• Не все механизмы базы данных поддерживают триггеры, поэтому ваше решение создает зависимости от двигателей баз данных.

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

Ответ 4

Триггеры могут быть очень полезными. Они также могут быть очень опасными. Я думаю, что они подходят для задач уборки дома, таких как заполнение данных аудита (созданных, измененная дата и т.д.), А в некоторых базах данных можно использовать для ссылочной целостности.

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

• это дополнительный слой кода для исследования
• иногда, как узнал OP, когда вам нужно исправить данные, триггер может делать что-то с предположением, что изменение данных всегда осуществляется с помощью директивы приложения, а не от разработчика или администратора баз данных, устраняющего проблему, или даже из другого приложения

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

Общее правило, которое я предпочитаю использовать с триггерами, заключается в том, чтобы держать их светлыми, быстрыми, простыми и неинвазивными, насколько это возможно.

Ответ 5

"Никогда не создавайте триггер для проверки целостности целостности, которая пересекает строки в таблице" - я не могу согласиться. В вопросе помечены "SQL Server", а условия ограничений CHECK в SQL Server не могут содержать подзапрос; хуже, реализация, похоже, имеет "жестко закодированное" предположение, что CHECK будет включать только одну строку, поэтому использование функции не является надежным. Поэтому, если мне нужно ограничение, которое законно включает более одной строки, и хорошим примером здесь является секвенсорный первичный ключ в классической временной таблице "допустимого времени", где мне нужно предотвратить периоды перекрытия для одного и того же объекта - как можно Я делаю это без триггера? Помните, что это первичный ключ, что-то, чтобы обеспечить целостность данных, поэтому принудительное использование его в любом месте, кроме СУБД, не может быть и речи. Пока ограничения CHECK не получат подзапросы, я не вижу альтернативы использованию триггеров для определенных ограничений целостности.

Ответ 6

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

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

В общем, я проголосую за "они служат цели в некоторых сценариях". Я всегда нервничаю в связи с последствиями для работы.

Ответ 7

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

Ответ 8

Я впервые использовал триггеры пару недель назад. Мы изменили производственный сервер с SQL 2000 на SQL 2005 и обнаружили, что драйверы ведут себя по-разному с полями NText (хранящими большой XML-документ), отбрасывая последний байт. Я использовал триггер в качестве временного исправления для добавления дополнительного фиктивного байта (пробела) в конец данных, решая нашу проблему, пока не будет развернуто правильное решение.

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

Ответ 9

Честно говоря, единственный раз, когда я использую триггеры для имитации уникального индекса, которому разрешено иметь NULL, который не учитывает уникальность.

Ответ 10

Что касается сокращения объема работы: базы данных потрясающе эффективны, когда им не приходится иметь дело с внешним миром; вы действительно удивитесь, насколько даже переключение процесса ухудшает производительность. Это еще один недостаток хранимых процедур: вместо дюжины звонков в базу данных (и все связанные с ней круглые поездки), там один.

это немного не по теме, но вы также должны знать, что вы смотрите только на это из одного потенциального положительного.

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

Ответ 11

Общий вентилятор,

но на самом деле нужно использовать его экономно, когда

• Необходимо поддерживать согласованность (особенно, когда таблицы размеров используются на складе, и нам нужно связать данные в таблице фактов с их надлежащим размером. Иногда правильная строка в таблице размеров может быть очень дорогой вычислите так, что вы хотите, чтобы ключ был написан прямо в таблице фактов, один хороший способ поддерживать, что "отношение" имеет триггер.

• Необходимо регистрировать изменения (например, в таблице аудита полезно знать, что пользователь @@выполнил изменение и когда он произошел)

Некоторые RDBMS, такие как sql server 2005, также предоставляют триггеры для операторов CREATE/ALTER/DROP (так что вы можете знать, кто создал какую таблицу, когда, удалил какой столбец, когда и т.д.)

Честно говоря, используя триггеры в этих трех сценариях, я не понимаю, зачем вам когда-либо нужно "отключать" их.

Ответ 12

Общее правило: не используйте триггеры. Как уже упоминалось ранее, они добавляют дополнительные служебные данные и сложность, которых легко избежать, перемещая логику из уровня БД.

Кроме того, в MS SQL Server триггеры запускаются один раз за команду sql, а не за строку. Например, следующая инструкция sql будет запускать триггер только один раз.

UPDATE tblUsers
SET Age = 11
WHERE State = 'NY'

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