Действительно ли база данных запускает зло?

Ответ 1

Основные проблемы с триггерами: a) они полностью глобальны - они применяются независимо от контекста активности таблицы; и б) они скрыты; легко забыть, что они там, пока они не навредят вам непреднамеренными (и очень таинственными) последствиями.

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

Ответ 2

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

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

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

Кроме того, отсутствие триггеров предотвратит применение правил данных в СУБД, таких как предварительные триггеры, чтобы гарантировать, что столбцы имеют определенный формат. Обратите внимание, что это отличается от правил целостности данных, которые обычно выглядят просто внешними ключами.

Ответ 3

Инструменты никогда не будут злыми. Применение этих инструментов может быть злым.

Ответ 4

Триггеры, похоже, хорошо работают для ведения журнала аудита.

Ответ 5

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

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

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

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

Они звучат суровыми, и я думаю, что они есть. Но это основная истина, на мой взгляд...

Ответ 6

Я думаю, что триггеры не только не злые, но необходимые для хорошего дизайна базы данных. Программисты приложений считают, что их применение зависит только от баз данных. Они часто ошибаются. Если целостность данных должна поддерживаться независимо от того, откуда произошло изменение данных, триггеры являются обязательным требованием, и глупо их избегать, потому что некоторые программисты слишком этноцентричны, чтобы считать, что что-то другое, чем их ценное приложение, может влиять на вещи. Если вы являетесь компетентным разработчиком базы данных, нетрудно спроектировать или протестировать или устранить неисправность триггера. Также трудно определить, что триггер вызывает неожиданный результат, если вам кажется (как и мне), чтобы посмотреть там. Если я получу ошибку, говоря, что таблица, в которой я не ссылаюсь в моей sp, имеет ошибку FK, я знаю, даже не думая об этом, что триггер вызывает проблему, и поэтому должен быть компетентный разработчик базы данных. Приведение бизнес-правил только в приложение является причиной номер один, из-за которой я обнаружил плохие данные, поскольку другие понятия не имеют, что правило существует и нарушает его в своих процессах. Основанные на данных правила относятся к базе данных, и триггеры являются ключевыми для обеспечения более сложных.

Ответ 7

В основном, да.

Трудность с триггером заключается в том, что он делает вещи "за спиной"; разработчик, поддерживающий приложение, может легко не осознавать его там и вносить изменения, которые заворачивают вещи, даже не замечая.

Он создает слой сложности, который просто добавляет работу по обслуживанию.

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

Ответ 8

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

Они также очень хороший инструмент "взлома". Часто возникают ситуации, когда вы не находитесь под непосредственным контролем как кода, так и базы данных. Если вам нужно подождать 2 месяца для следующего крупного выпуска вашего кода, но вы можете сразу применить патч к своей базе данных, тогда вы можете поместить триггер в таблицу для выполнения некоторых дополнительных функций. Затем, когда возможна версия кода, вы можете заменить этот триггер на свою кодированную версию той же функциональности, если это необходимо.

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

Ответ 9

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

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

Существует также проблема "принципа наименьшего удивления", о которой уже говорилось.

Ответ 10

Триггеры - хороший инструмент при правильном использовании. Особенно для таких вещей, как ревизия изменений, заполнение таблиц суммирования и т.д.

Теперь они могут быть "злыми", если вы попадете в "триггерный ад" с одним триггером, который запускает другие триггеры. Я когда-то работал над продуктом COTS, где у них было то, что они называли "триггерами". Эти триггеры были сохранены в таблице, так как динамические sql stings были скомпилированы каждый раз, когда они были выполнены. Скомпилированные триггеры будут искать и посмотреть, есть ли в этой таблице какие-либо триггеры для запуска, а затем скомпилировать и запустить триггер "flex". Теоретически это звучало как действительно классная идея, потому что продукт был легко настроен, но реальность была в значительной степени взорвана из-за всех компиляций, которые он должен был сделать...

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

Ответ 11

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

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

Ответ 12

Не злой. Они фактически упрощают такие вещи, как

1. Регистрация/ревизия изменений в записях или даже схемах базы данных

У вас может быть триггер на ALTER TABLE, который откатывает изменения в рабочей среде. Это должно предотвратить любые случайные изменения таблицы.

2. Внедрение ссылочной целостности (отношения первичного/внешнего ключа и т.д.) в нескольких базах данных

Ответ 13

Нет, они не злые - их просто неправильно поняли:-D

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

Если вы разрабатываете БД как часть приложения, логика всегда должна быть в коде или sprocs, вызывающем вызов. Триггеры просто приведут к боли отладки позже.

Если вы понимаете, как блокировка, взаимоблокировка и доступ DB к файлам на диске, то использование триггеров в правильном направлении (например, аудит или архивирование прямого доступа к БД) может быть действительно ценным.

Ответ 14

Они определенно не злые. Я нашел триггеры ценными при реорганизации схем баз данных, переименовывая столбец или разбивая столбцы на два столбца или наоборот (пример: имя/фамилия) и помогая переходу.

Они также очень полезны для аудита.

Ответ 15

Этот ответ относится конкретно к SQL Server. (хотя он может также применяться к другим РСУБД, о которых я понятия не имею. Я бы предпочел дать его как ответ здесь, но это было закрыто как обман этого.)

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

Пример, приведенный в BOL под заголовком Управление триггерной безопасностью" пользователя, который создает триггер, содержащий код GRANT CONTROL SERVER TO JohnDoe ; чтобы увеличить свои собственные разрешения.

Ответ 16

На высоком уровне есть два варианта использования триггеров1

1) Сделать вещи "автоматически". В этом случае триггеры вызывают побочный эффект, они изменяют данные способами, которые не ожидались, учитывая (примитивный) оператор вставлять, обновлять или удалять, что было выполнено, и вызвало срабатывание триггера.

Общее мнение здесь состоит в том, что триггеры действительно вредны. Потому что они изменяют хорошо известную семантику оператора INSERT, UPDATE или DELETE. Изменение семантики этих трех примитивных операторов SQL укусит других разработчиков, которым позже в будущем придется работать над таблицами базы данных, которые больше не ведут себя ожидаемыми способами, когда они работают с ними с помощью примитивов SQL.

2) Обеспечить соблюдение правил целостности данных, отличных от тех, с которыми мы можем работать декларативно (используя CHECK, PRIMARY KEY, UNIQUE KEY и FOREIGN KEY). В этом случае все триггеры - это данные QUERY (SELECT), чтобы проверить, разрешено или нет изменение, которое делается INSERT/UPDATE/DELETE. Так же, как декларативные ограничения для нас. Только в этом случае мы (разработчики) запрограммировали принудительное выполнение.

Использование триггеров для последнего варианта использования не является вредным.

Я занимаюсь ведением блога: http://harmfultriggers.blogspot.com

Ответ 17

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

Ответ 18

Я думаю, что они могут быть злыми, но только как зло, как все остальное в развитии.

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

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

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

Ответ 19

Сказать, что они злые, - это преувеличение, но они могут вызвать сетку. Когда стрельба из одного триггера вызывает срабатывание других триггеров, он становится очень сложным. Пусть говорят, что они хлопотливы: http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

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

Ответ 20

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

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

Ответ 21

Идея триггеров не является злом, ограничение гнездования триггеров - это зло.