Подтвердить что ты не робот

Каскад для удаления или использования триггеров?

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

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

Im, использующий MSSQL 2008.

4b9b3361

ОТВЕТЫ

Ответ 1

CASCADE DELETE в MSSQL Server может только каскадироваться в одну таблицу. Если в таблице измерений есть две таблицы с отношениями внешних ключей, вы можете только каскадировать удаление до одного из них. (Это делается для предотвращения удаления каскадирования через несколько путей и создания конфликтов, так как С++ допускает множественное наследование, но С# допускает только одно наследование)

Если это так, вы вынуждены использовать триггеры или специально обрабатывать регистр в своем коде.

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

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

EDIT:

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

У вас может быть несколько таблиц фактов, которые включены. УДАЛИТЬ CASCADE Внешние ключи для таблиц с таблицей.

То, что вы не можете сделать, - это иметь одну таблицу фактов, чтобы УДАЛИТЬ ограничения CASCADE для внешних ключей для нескольких таблиц измерений.

Итак, например... - Таблица размеров [Лицо] (id INT IDENTITY,)
- Таблица размеров [Экзамен] (id INT IDENTITY,)
- Таблица лиц [Exam_Score] (person_id INT, exam_id INT, оценка INT)

Если либо Лицо, либо Экзамен удалены, вы также должны удалить ассоциированные записи Exam_Score.

Это невозможно, используя ON DELETE CASCADE в MS SQL Server, поэтому необходимость в триггерах.

(Извиняется Мехрдаду, который пытался объяснить это мне, но я полностью упустил его точку.)

Ответ 2

Держитесь подальше от ненужных триггеров.

Перейдите с ON DELETE CASCADE, если это все, что вам нужно сделать.

Ответ 3

Я бы использовал каскад при удалении, но это только если вы определенно хотите удалить дочерний элемент, если родитель удален.

Если у вас есть условная логика (я удаляю только дочерний элемент, если он удален в воскресенье), используйте триггер.

Я бы просто изменил его на cascade on delete, на систему разработки, затем запустил модульные тесты и убедился, что ничего не сломается.

Ответ 4

Я почти согласен с Dems здесь, за исключением того, что использую ON DELETE CASCADE (и ON UPDATE CASCADE) как можно референтные действия и только прибегать к использованию триггеров, где это необходимо. Я бы также рассмотрел отмену разрешений из таблиц и принудительное использование хранимых процедур для помощников для удаления и обновления.

Назовите меня оптимистом, но я верю a) мой код выживет, перенося на будущую версию MS SQL Server, и b) команда SQL Server в один прекрасный день скоро приблизится к исправлению ограничения "одного каскадного пути", на котором point Я заменил триггеры каскадными ссылочными действиями:)