Мне любопытно, могу ли я полагаться на какой-либо конкретный порядок проверки NOT NULL, FOREIGN KEY, UNIQUE, CHECK ограничений и BEFORE триггеров.
По опыту знаю, что MySQL сначала проверяет NOT NULL, затем запускает BEFORE триггер, а затем проверяет UNIQUE ограничения. Oracle проверяет NOT NULL после триггера BEFORE (думаю, SQLServer делает то же самое, но не помню). Говорит ли стандарт что-нибудь о заказе или это полностью зависит от поставщика БД?
Такое поведение похоже на ошибку в MySQL и влияет только на BEFORE INSERT триггеров. , а триггеры BEFORE UPDATE ведут себя корректно.
В стандарте (как указано в комментариях к вопросу), конечно, это не указано явно, но это определенно подразумевается:
Для каждого изменения состояния SCi,j в TECi триггеры BEFORE, активированные SCi,j, выполняются до того, как вступят в силу какие-либо из их триггерных событий. Когда эти триггерные события вступили в силу, выполняются все триггеры AFTER, активированные изменениями состояния TECi.
Ошибка NOT NULL должна быть частью INSERT или UPDATE (т.е. инициирующего события). Стандарт не должен указывать это. Нет абсолютно нет смысла предварительно проверять ограничения на набор изменений, которые не являются окончательными, потому что ваш BEFORE триггер способен как устранять ошибки, и добавлять новые.
РЕЗЮМЕ. На самом деле это не зависит от поставщика БД, поскольку проверка ограничений после триггера «до» всегда необходима.
before. Это позволяет триггеруbeforeизменять значения так, чтобы они больше не были нулевыми. - person Shannon Severance schedule 22.11.2011Instead Of Trigger Entered ,Check NULL constraint, Unique constraints, check constraints, FK, After Trigger, Instead Of Trigger Exitedот тестирования, которое я провел, чтобы ответить на этот вопрос - person Martin Smith schedule 23.11.2011BEFORE TRIGGER(конечно, если RMDS поддерживает это) против ограничений. - person a1ex07 schedule 23.11.2011