Когда и зачем использовать каскадирование в SQL Server?

Question

При настройке внешних ключей в SQL Server, при каких обстоятельствах он должен каскадироваться при удалении или обновлении и каковы причины этого?

Это, вероятно, относится и к другим базам данных.

Больше всего я ищу конкретные примеры каждого сценария, желательно от того, кто их успешно использовал.

Answer 1

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

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

Answer 2

Я стараюсь избегать удалений или обновлений, которые я явно не запрашивал в SQL-сервере.

Либо путем каскадирования, либо с помощью триггеров. Как правило, они кусают вас в задницу некоторое время, либо при попытке отследить ошибку, либо при диагностике проблем с производительностью.

Я бы использовал их в том, чтобы гарантировать последовательность при не очень больших усилиях. Чтобы получить тот же эффект, вам придется использовать хранимые процедуры.

Answer 3

Удаление или обновление S, которое удаляет значение внешнего ключа, найденное в некоторых кортежах R, может быть обработано одним из трех способов:

1. Отказ
2. Распространение
3. обнуление.

Распространение называется каскадным.

Есть два случая:

‣ Если кортеж в S был удален, удалите кортежи R, которые ссылались на него.

‣ Если кортеж в S был обновлен, обновите значение в кортежах R, которые к нему относятся.

Answer 4

Каскадное удаление чрезвычайно полезно при реализации логических сущностей супертипа и подтипа в физической базе данных.

Когда отдельные таблицы супертипа и подтипа используются для физической реализации супертипов / подтипов (в отличие от свертывания всех атрибутов подтипа в одну физическую таблицу супертипа), существует Отношение «один к одному» между этими таблицами и вопросом заключается в том, как обеспечить 100% синхронизацию первичных ключей между этими таблицами.

Каскадное удаление может быть очень полезным инструментом для:

1) Убедитесь, что удаление записи супертипа также удаляет соответствующую отдельную запись подтипа.

2) Убедитесь, что любое удаление записи подтипа также удаляет запись супертипа. Это достигается путем реализации триггера удаления «вместо» в таблице подтипов, который отправляет и удаляет соответствующую запись супертипа, что, в свою очередь, каскадно удаляет запись подтипа.

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

Answer 5

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

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

Однако в таблицах списков, похожих на перечисление, это плохо: кто-то удаляет запись 13 - желтый из таблицы «colors», и все желтые элементы в базе данных удаляются. Кроме того, они иногда обновляются способом delete-all-insert-all, что приводит к полной пропущенной ссылочной целостности. Конечно, это неправильно, но как вы измените сложное программное обеспечение, работающее в течение многих лет, когда внедрение истинной ссылочной целостности может привести к неожиданным побочным эффектам?

Другая проблема заключается в том, что исходные значения внешнего ключа должны сохраняться даже после удаления первичного ключа. Можно создать столбец-захоронение и опцию ON DELETE SET NULL для исходного FK, но для этого снова требуются триггеры или специальный код для сохранения избыточного (кроме после удаления PK) значения ключа.