Вопросы производительности для триггеров и ограничений

Question

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

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

Answer 1

@ Meff: существуют потенциальные проблемы с подходом использования функции, потому что, проще говоря, ограничения CHECK SQL Server были разработаны с одной строкой в ​​качестве единицы работы и имеют недостатки при работе с набором результатов. Подробнее об этом см .: [http://blogs.conchango.com/davidportas/archive/2007/02/19/Trouble-with-CHECK-Constraints.aspx][1].

[1]: Блог Дэвида Портаса: проблема с ограничениями CHECK.

Answer 2

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

Существует тенденция к чрезмерному использованию триггеров, особенно с новыми разработчиками. Я видел ситуации, когда триггер запускает другой триггер, который запускает другой триггер, который повторяет первый триггер, создавая каскадный триггер, который связывает ваш сервер. Это неоптимальный пользователь триггеров; о)

При этом триггеры имеют свое место и должны использоваться при необходимости. Они особенно хороши для отслеживания изменений в данных (как упоминал Марк Брэкетт). Вам нужно ответить на вопрос «Где больше всего смысла использовать мою бизнес-логику»? Большую часть времени я думаю, что это относится к коду, но вы должны сохранять непредвзятость.