Каскад на Удалить или использовать триггеры?
Я прохожу через проект, который я взял на себя, и на стороне базы данных я заметил, что предыдущие программисты написали кучу триггеров для удаления дочерних записей. Дело в том, что эти записи уже имеют отношение внешнего ключа к родительской записи, которую я удаляю. Триггеры delete - это не что иное, как простые инструкции delete для дочерних записей.
есть ли преимущество в написании триггера для удаления дочерних записей или я могу просто изменить его на cascade на Удалить и быть в порядке?
Im с помощью MSSQL 2008.
4 ответов
КАСКАДНОЕ УДАЛЕНИЕ в MSSQL Server можно каскадировать только в одну таблицу. Если у вас есть две таблицы с отношениями внешнего ключа к таблице измерений, вы можете каскадно удалить только одну из них. (Это необходимо для предотвращения каскадного удаления по нескольким путям и создания конфликтов, так как C++ допускает множественное наследование, но C# допускает только одно наследование)
когда это так, вы вынуждены использовать триггеры или специально обрабатывать случай в вашем код.
по этой причине я видел, что многие люди выбирают использование триггеров во всех случаях. Даже когда есть только один иностранный стол. Это обеспечивает согласованность, и поэтому люди знают, что искать при обслуживании базы данных.
Если бы можно было каскадировать удаление более чем в одну таблицу, я бы сказал, что это был бы наиболее предпочтительный вариант. Это ограничение, однако, мутит воду, и в настоящее время я больше за триггеры, владеющие всеми такими поведениями. Накладные расходы использование триггеров для каскадных удалений и обновлений является незначительным с точки зрения кодирования, но позволяет применять стандартные методы, которые являются действительно универсальными.
изменить:
возможно, вы захотите перенести "принятый ответ" на кого-то другого, я понял, что ошибался в этом выше.
вы можете иметь несколько таблиц фактов для удаления каскадных внешних ключей, противопоставленных таблице размеров signle.
чего вы не можете сделать, так это иметь одну таблицу фактов имейте на Удалить каскадные ограничения внешнего ключа для нескольких таблиц измерений.
Так, например...
- Таблица измерений [человек] (id int IDENTITY, )
- Таблица измерений [экзамен] (ID int IDENTITY,)
- Таблица лица [Exam_Score] (person_id INT, exam_id INT, оценка INT)
Если человек или экзамен удалены, вы хотите, чтобы связанные Exam_Score запись(ы) также будут удалены.
Это невозможно использовать при удалении каскада в MS SQL Server, таким образом, потребность в триггерах.
(извиняюсь перед Мехрдадом, который пытался объяснить мне это, но я полностью пропустил его точку зрения.)
держитесь подальше от ненужных триггеров.
идете с ON DELETE CASCADE Если это все, что вам нужно сделать.
Я бы использовал каскад при удалении, но это только если вы определенно хотите удалить ребенка, если родитель удален.
Если у вас есть какая-либо условная логика (я удаляю только ребенка, если он удален в воскресенье), используйте триггер.
Я бы просто изменил его на cascade on delete, в системе разработки, затем запустите мои модульные тесты и убедитесь, что ничего не ломается.
я почти согласен с Dems здесь, кроме я использую ON DELETE CASCADE (и ON UPDATE CASCADE если на то пошло) ссылочные действия везде, где это возможно, и только прибегают к использованию триггеров, где это необходимо. Я бы также рассмотрел возможность отмены разрешений из таблиц и принудительного использования "вспомогательных" хранимых процессов для удаления и обновления.
Назовите меня оптимистом, но я считаю, что a) мой код переживет перенос на будущий выпуск MS SQL Server и b) команда SQL Server в один прекрасный день скоро приступит к исправлению ограничение "один каскадный путь", в этот момент я заменю триггеры каскадными ссылочными действиями:)