Может кто-нибудь объяснить (или предложить сайт или документ) точную разницу между триггерами, утверждениями и проверками, также описать, где я должен их использовать?
EDIT: Я имею в виду в базе данных, а не в каких-либо других системах или языках программирования.
Триггеры - триггер - это часть SQL, выполняемая до или после обновления, вставки или удаления в базе данных. Пример триггера на простом английском языке может выглядеть примерно так: перед обновлением записи клиента сохраните копию текущей записи. Что бы выглядело примерно так:
CREATE TRIGGER triggerName
AFTER UPDATE
INSERT INTO CustomerLog (blah, blah, blah)
SELECT blah, blah, blah FROM deleted
Разница между утверждениями и проверками немного более мутная, многие базы данных даже не поддерживают утверждения.
Проверить ограничение. Проверка - это часть SQL, которая гарантирует, что условие выполнено до того, как действие может быть выполнено в записи. На простом английском языке это будет примерно так: у всех клиентов должен быть баланс на счете не менее 100 долларов на их счете. Что бы выглядело примерно так:
ALTER TABLE accounts
ADD CONSTRAINT CK_minimumBalance
CHECK (balance >= 100)
Любая попытка вставить значение в столбце баланса менее 100 приведет к ошибке.
Утверждения. Утверждение - это часть SQL, которая гарантирует выполнение условия или прекращает действие, выполняемое в объекте . Это может означать блокировку всей таблицы или даже всей базы данных.
Чтобы сделать вещи более запутанными - триггер можно использовать для принудительного ограничения проверки, и в некоторых БД может заменить утверждение (позволяя запускать код, не связанный с изменяемой таблицей). Общей ошибкой для новичков является использование контрольного ограничения, когда требуется триггер или триггер, когда требуется ограничение проверки.
Пример: все новые клиенты, открывающие счет, должны иметь остаток в размере 100 долларов США; однако после открытия учетной записи их баланс может упасть ниже этой суммы. В этом случае вам нужно использовать триггер, потому что вы хотите, чтобы условие было оценено при вставке новой записи.
В стандарте SQL оба утверждения и CHECK CONSTRAINTS - это то, что реляционная теория называет "ограничениями": правила, которые фактические данные, содержащиеся в базе данных, должны соответствовать.
Разница между двумя заключается в том, что CHECK CONSTRAINTS в некотором смысле намного проще, это правила, которые относятся только к одной строке, в то время как ASSERTION могут включать любое количество других таблиц или любое количество других строк в той же таблице. Это, очевидно, делает его (намного!) Более сложным для строителей СУБД для его поддержки, а это, в свою очередь, причина, почему они этого не делают: они просто не знают, как это сделать.
TRIGGER - это фрагменты исполняемого кода, из которых он может быть объявлен в СУБД, что они должны выполняться каждый раз, когда выполняется определенная операция обновления (вставка/удаление/обновление) в определенной таблице. Поскольку триггеры могут генерировать исключения, они являются СРЕДСТВАМИ для реализации того же самого, что и УКАЗАНИЕ. Однако с триггерами он все еще программист, который должен делать все кодирование и не делать никакой ошибки.
ИЗМЕНИТЬ
Onedaywhen комментарии re. УКАЗАНИЕ/ПРОВЕРКА cnstr. являются правильными. Разница более тонкая (и запутанная). Стандарт действительно позволяет подзапросы в ограничениях CHECK. (Большинство продуктов не поддерживают его, поэтому моя "относится к одной строке" верна для большинства продуктов SQL, но не для стандартного.) Так есть ли разница? Да, есть еще. Более одного даже.
Первый случай: TABLE MEN (ID: INTEGER) и TABLE WOMEN (ID: INTEGER). Теперь представьте правило о том, что "значение ID не может появляться как в MEN, так и в таблице WOMEN". Это одно правило. Цель ASSERTION заключается именно в том, что разработчик базы данных укажет это единственное правило [и будет сделано с ним], и СУБД будет знать, как справиться с этим [эффективно, конечно] и как обеспечить соблюдение этого правила, независимо от того, что конкретно обновление выполняется в базе данных. В этом примере СУБД будет знать, что для этого правила необходимо выполнить проверку для INSERT INTO MEN, а также INSERT INTO WOMEN, но не DELETE FROM MEN/WOMEN или INSERT INTO <anyothertable> .
Но СУБД недостаточно умен, чтобы делать все это. Итак, что нужно сделать? Дизайнер базы данных должен добавить к своей базе данных TWO CHECK ограничения, один - в таблицу MEN (проверка вновь вставленного идентификатора MEN на таблицу WOMEN) и одну на таблицу WOMAN (проверка в обратном порядке). Там ваше первое различие: одно правило, одно ограничение, два ограничения CHECK. Ограничения CHECK - это более низкий уровень абстракции, чем НАЗНАЧЕНИЯ, поскольку они требуют от дизайнера больше думать о (а) обо всех обновлениях, которые могут привести к нарушению его НАБЛЮДЕНИЯ, и (б) какая конкретная проверка должна быть выполнена для любого из конкретных "видов обновления", которые он нашел в (а). (Хотя мне не очень нравится делать "абсолютные" утверждения о том, что все еще "ЧТО" и что такое "КАК", я бы подвел итог, что ограничения CHECK требуют больше "HOW" мышления (процедурного) дизайнера базы данных, тогда как ASSERTIONs позволить разработчику базы данных сосредоточиться исключительно на "ЧТО" (декларативный).)
Второй случай (хотя я не совсем уверен в этом - так возьмите с солью): просто ваше среднее правило RI. Конечно, вы привыкли указывать это, используя предложение REFERENCES. Но представьте, что предложение REFERENCES недоступно. Правило типа "Каждый ЗАКАЗ должен быть помещен известным ЗАКАЗЧИКОМ", на самом деле это правило, таким образом: единый УКАЗАТЕЛЬ. Однако мы все знаем, что такое правило всегда может быть нарушено двумя способами: вставка ORDER (в этом примере) и удаление ЗАКАЗЧИКА. Теперь, в соответствии с вышеприведенным примером MAN/WOMEN, если мы хотим реализовать это единственное правило /ASSERTION с использованием ограничений CHECK, тогда нам нужно написать ограничение CHECK, которое проверяет существование CUSTOMER при вставках в ORDER, но какое ограничение CHECK могло бы мы пишем, что делает все, что необходимо при удалении от CUSTOMER? Насколько мне известно, они просто не предназначены для этой цели. Там ваше второе различие: ограничения CHECK привязаны исключительно к INSERT, ASSERTIONS могут определять правила, которые также будут проверяться с помощью DELETE.
Третий случай: представьте таблицу COMPOS (componentID:... percent: INTEGER) и правило о том, что "сумма всех процентов должна быть всегда равна 100". Это одно правило, и УКАЗАНИЕ может указать это. Но попробуйте представить, как вы собираетесь применять такое правило с ограничениями CHECK... Если у вас есть действительная таблица с, скажем, тремя ненулевыми строками, суммирующимися до ста, как бы вы применили какое-либо изменение к этой таблице, которая могла бы выжить ваше ограничение CHECK? Вы не можете удалять или обновлять (уменьшать) любую строку без необходимости добавления других замещающих строк или обновлять оставшиеся строки, которые суммируются до одного и того же процента. Аналогично для вставки или обновления (увеличения). Вам потребуется отсроченная проверка ограничений, по крайней мере, и что вы собираетесь проверять? Там ваше третье отличие: ограничения CHECK нацелены на отдельные строки, в то время как ASSERTIONs также могут определять/выражать правила, которые "охватывают" несколько строк (т.е. Правила об агрегации строк).
Утверждения не изменяют данные, они проверяют только определенные условия
Триггеры более мощные, так как могут проверять условия, а также изменять данные
Утверждения не связаны с конкретными таблицами в базе данных и не связаны с конкретными событиями
Триггеры связаны с конкретными таблицами и конкретными событиями
Ограничение базы данных включает условие, которое должно выполняться при обновлении базы данных. В SQL, если условие ограничения оценивается как false, обновление не выполняется, данные остаются неизменными, и СУБД генерирует ошибку.
Оба CHECK и ASSERTION - это ограничения базы данных, определенные стандартами SQL. Важным отличием является то, что a CHECK применяется к конкретной базовой таблице, тогда как ASSERTION применяется ко всей базе данных. Рассмотрим ограничение, которое ограничивает объединенные строки в таблицах T1 и T2 до 10 строк, например.
CHECK (10 >= (
SELECT COUNT(*)
FROM (
SELECT *
FROM T1
UNION
SELECT *
FROM T2
) AS Tn
))
Предположим, что таблицы пусты. Если это было применено только как ASSERTION, и пользователь попытался вставить 11 строк в T1, тогда обновление завершится неудачно. То же самое применимо, если ограничение было применено только как ограничение CHECK только для T1. Однако, если ограничение было применено как ограничение CHECK к T2, только ограничение было бы успешным, потому что таргетинг на инструкцию T1 не вызывал проверки ограничений, применяемых к T1.
Оба ASSERTION и CHECK могут быть отложены (если объявлено как DEFERRABLE), что позволяет временно нарушать условие ограничения, но только внутри транзакции.
ASSERTION и CHECK ограничения, связанные с подзапросами, являются функциями вне основного стандарта SQL, и ни один из основных продуктов SQL не поддерживает эти функции. MS Access (не совсем промышленно-прочный продукт) поддерживает ограничения CHECK, связанные с подзапросами, но не отложенные ограничения, а тестирование ограничений всегда выполняется по очереди за строкой, что является практическим следствием того, что функциональность очень ограничена.
Как правило, с ограничениями CHECK триггер применяется к конкретной таблице. Поэтому триггер можно использовать для реализации той же логики, что и ограничение CHECK, но не ASSERTION. Триггер - это процедурный код и, в отличие от ограничений, пользователь должен взять на себя большую ответственность за такие проблемы, как производительность и обработка ошибок. Большинство коммерческих SQL-продуктов поддерживают триггеры (в вышеупомянутом MS Access нет).
Выражение должно быть истинным для запуска триггера, но проверка будет оцениваться везде, где выражение ложно.