что является различием между триггерами, утверждениями и проверками (в базе данных)

В стандарте SQL как ASSERTIONS, так и CHECK CONSTRAINTS - это то, что в реляционной теории называется «ограничениями»: правила, которым должны соответствовать данные, фактически содержащиеся в базе данных.

Разница между ними в том, что ПРОВЕРКА ОГРАНИЧЕНИЙ, в некотором смысле, намного «проще»: это правила, которые относятся только к одной единственной строке, в то время как УТВЕРЖДЕНИЯ могут включать любое количество других таблиц или любое количество других строк. в той же таблице. Это, очевидно, усложняет (намного!) Поддержку разработчикам СУБД, и это, в свою очередь, причина того, почему они этого не делают: они просто не знают, как это сделать.

ТРИГГЕРЫ - это фрагменты исполняемого кода, для которых СУБД может быть объявлено, что они должны выполняться каждый раз, когда определенный вид операции обновления (вставка / удаление / обновление) выполняется для определенной таблицы. Поскольку триггеры могут вызывать исключения, они являются СРЕДСТВАМИ для реализации того же, что и УТВЕРЖДЕНИЕ. Однако в случае с триггерами программист по-прежнему должен делать все кодирование и не допускать ошибок.

РЕДАКТИРОВАТЬ

Однажды, когда комментарии касаются. УТВЕРЖДЕНИЕ / ПРОВЕРКА cnstr. верны. Разница более тонкая (И сбивающая с толку). Стандарт действительно разрешает подзапросы в ограничениях CHECK. (Однако большинство продуктов не поддерживают его, поэтому мое «относиться к одной строке» верно для большинства продуктов SQL, но не для стандарта.) Так есть ли еще разница? Да еще есть. Даже больше, чем один.

Первый случай: TABLE MEN (ID: INTEGER) и TABLE WOMEN (ID: INTEGER). Теперь представьте себе правило, согласно которому «никакое значение ID не может появляться ни в таблице МУЖЧИН, ни в таблице ЖЕНЩИН». Это единое правило.Цель ASSERTION состоит в том, чтобы разработчик базы данных сформулировал это единственное правило [и покончил с ним], а СУБД знала, как с этим справиться [эффективно, конечно] и как обеспечить соблюдение этого правила, независимо от того, какое именно обновление выполняется в базе данных. В этом примере СУБД будет знать, что она должна выполнить проверку этого правила при INSERT INTO MEN и INSERT INTO WOMEN, но не при DELETE FROM MEN / WOMEN или INSERT INTO .

Но СУБД недостаточно умны для всего этого. Итак, что нужно сделать? Разработчик базы данных должен добавить ДВА ограничения CHECK в свою базу данных, одно - в таблицу MEN (сверяя вновь вставленные идентификаторы MEN с таблицей WOMEN) и одно - в таблицу WOMAN (проверяя наоборот). Вот ваше первое отличие: одно правило, одно ASSERTION, ДВА CHECK ограничения. Ограничения CHECK представляют собой более низкий уровень абстракции, чем ASSERTION, потому что они требуют от дизайнера больше думать о (а) обо всех видах обновлений, которые потенциально могут привести к нарушению его ASSERTION, и (b) о том, какая конкретная проверка должна выполняться для любого из конкретных «видов обновлений», которые он нашел в (а). (Хотя мне не очень нравится делать «абсолютные» утверждения о том, что остается «ЧТО», а что «КАК», я бы резюмировал, что ограничения CHECK требуют большего (процедурного) мышления со стороны разработчика базы данных, тогда как утверждения ASSERTION позвольте проектировщику базы данных сосредоточиться исключительно на «ЧТО» (декларативно).)

Второй случай (хотя я не совсем уверен в этом - так что относитесь с недоверием): просто ваше среднее правило RI.Конечно, вы привыкли указывать это с помощью некоторого предложения REFERENCES. Но представьте, что предложение REFERENCES недоступно. Правило типа «Каждый ЗАКАЗ должен быть размещен известным ЗАКАЗЧИКОМ» на самом деле является правилом, а именно: одно УТВЕРЖДЕНИЕ. Однако все мы знаем, что такое правило всегда можно нарушить двумя способами: вставив ЗАКАЗ (в этом примере) и удалив ЗАКАЗЧИК. Теперь, в соответствии с приведенным выше примером MAN / WOMEN, если бы мы хотели реализовать это единственное правило / ASSERTION с использованием ограничений CHECK, тогда нам пришлось бы написать ограничение CHECK, которое проверяет существование CUSTOMER при вставке в ORDER, но какое ограничение CHECK может мы пишем, что делает все необходимое после удаления из CUSTOMER? Насколько я могу судить, они просто не предназначены для этой цели. Есть ваше второе отличие: ограничения CHECK привязаны исключительно к INSERT, ASSERTIONS могут определять правила, которые также будут проверяться при DELETE.

Третий случай: представьте себе таблицу COMPOS (componentID: ... процент: INTEGER) и правило, гласящее, что «сумма всех процентов всегда должна быть равна 100». Это единственное правило, и ASSERTION может это указать. Но попробуйте представить, как бы вы применили такое правило с ограничениями CHECK ... Если у вас есть действительная таблица, скажем, с тремя ненулевыми строками в сумме до сотни, как бы вы применили к этой таблице любое изменение, которое могло бы сохраниться? ваше ограничение CHECK? Вы не можете удалить или обновить (уменьшить) любую строку без добавления других заменяющих строк или обновить оставшиеся строки, которые в сумме составляют тот же процент.Аналогично для вставки или обновления (увеличения). Вам понадобится как минимум отложенная проверка ограничений, а затем что вы собираетесь ПРОВЕРИТЬ?Есть ваше третье отличие: ограничения CHECK нацелены на отдельные строки, в то время как ASSERTION могут также определять / выражать правила, которые «охватывают» несколько строк (то есть правила агрегирования строк).