Соображения производительности для Триггеров по сравнению с Ограничениями

Лучшая практика : если можно сделать это с ограничением, используйте ограничение.

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

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

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

В дополнение к другим причинам использовать ограничения, оптимизатор Oracle может использовать ограничения для, он - преимущество.

, Например, если у Вас есть ограничение, говоря (Amount >= 0) и затем Вы запрашиваете с WHERE (Amount = -5), Oracle сразу знает, что нет никаких строк соответствия.

Ограничения и триггеры для 2 разных вещей. Ограничения привыкли к , ограничивают домен (допустимые исходные данные) Ваших данных. Например, SSN был бы сохранен как символ (9), но с ограничением [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] (все числовые).

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

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

Триггеры могут превратиться в проблему производительности. В то же время, которое происходит, они также стали кошмаром обслуживания. Вы не можете выяснить то, что происходит и (премия!) приложение ведет себя беспорядочно с "побочными" проблемами данных. [Действительно, они - триггерные проблемы.]

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

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

, "Как я получаю абсолютное обеспечение что общее использование модели данных правильно?"

Два (с половиной) метода.

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

2. Справка определяют слой бизнес-модели приложений. Слой кода приложения, который все совместно используют и повторные использования.

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

Триггеры являются неизбежной железнодорожной аварией. Ограничения не.

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

@onedaywhen

у Вас может быть запрос как ограничение в SQL Server, Вы просто, должен смочь приспособить его в скалярной функции: http://www.eggheadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx

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

[1]: Блог David Portas: Проблема с ограничениями CHECK.

Если при всех ограничениях возможного применения. Они имеют тенденцию быть slighlty быстрее. Триггеры должны использоваться для сложной логики, которую не может обработать ограничение. Триггерная запись хитра также и если Вы находите, что необходимо записать триггер, удостоверьтесь, что использовали основанные на наборе операторы becasue triigers, работают против целой вставки, обновляют или удаляют (Да будут времена, когда больше чем одна запись будет затронута, запланируйте это!), не всего одна запись за один раз. Не используйте курсор в триггере, если его можно избежать.

Как далеко, поместить ли логику в приложение вместо триггера или ограничения. НЕ ДЕЛАЙТЕ ЭТОГО!!! Да, приложения должны иметь проверки, прежде чем они отправят данные, но целостность данных и бизнес-логика должны быть на уровне базы данных, или Ваши данные будут испорчены, когда несколько рычагов приложений в него, когда глобальный вставки будут сделаны вне приложения и т.д. Целостность данных является ключевой для баз данных и должна быть осуществлена на уровне базы данных.

@Mark Brackett: "Ограничения используются для ограничения домена... Триггеры являются способом осуществить бизнес-логику": Дело не в этом простой в SQL Server, потому что функциональность его ограничений ограничена, например, еще полный SQL-92. Возьмите классический пример упорядоченного 'первичного ключа' во временной таблице базы данных: идеально я использовал бы ограничение CHECK с подзапросом для предотвращения перекрывающихся периодов для того же объекта, но SQL Server не может сделать этого так, я должен использовать триггер. Также отсутствие от SQL Server является способностью SQL-92 задержать проверку ограничений, но вместо этого они (в действительности) проверяются после каждого SQL-оператора поэтому снова триггер может быть необходимым для работы вокруг ограничений SQL Server.

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

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

Однако триггеры имеют свое место и должны использоваться в надлежащих случаях. Они особенно хороши для отслеживания изменений в данных (как упомянутый Mark Brackett). Необходимо ли ответить на вопрос, "Где он имеет большую часть смысла поместить мою бизнес-логику"? Большую часть времени я думаю, что это принадлежит кода, но необходимо отнестись непредвзято.