Когда каскадное обновление это плохо?

Question

[MatveyGogolev]

Здравствуйте, у меня есть 2 вопроса про реляционные БД:
1. Когда каскадное обновление это плохо?
2. Когда имеет смысл ставить null во внешнем ключе?

Answer 1

[Akina]

Когда каскадное обновление это плохо?

Каскадное обновление - в большинстве случаев это... глупо.

Вспомним, что это вообще такое.

Имеется связь, реализованная внешним ключом. Некое поле (в общем случае - выражение) основной таблицы, уникально индексированное, является значением, на которое ссылается некое поле (или выражение) подчинённой таблицы (возможно, и той же самой).

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

Что же есть каскадное обновление? Это изменение связанного значения в подчинённой таблице, если изменяется значение основной таблицы. Ну то есть если изменяется (вспоминаем сказанное выше) значение первичного ключа или поля, объявленного уникальным. В основной таблице. Ага...

Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

Практически всё то же относится и к корректировке просто уникального поля. За исключением случая, когда выполняется каскадное изменение значения поля, которое в основной таблице получило значение NULL. То есть когда выполняемая операция по смыслу является не обновлением, а "мягким удалением" основной записи с каскадным удалением всех подчинённых. Правда, на вопрос, как отличить мягко каскадно-удалённые подчинённые записи от мягко явно-удалённых, и как определить, с какой основной записью была связана мягко удалённая подчинённая, не залезая в журнал или бэкап, ответа никто не даст. А получается, что даже в случае исключения всё делается через "универсальный интерфейс", то есть косяк в проектировании структуры имеется и в этом случае.

Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.

Answer 2

[Сергей Соловьев]

1. Когда сильно влияет на производительность
2. Когда ни на кого не ссылается

Answer 3

[Сергей delphinpro]

Второе очевидно - когда запись не имеет жесткой привязки и должна сохранится при удалении связанной (это про cascade delete), то связь следует выставить в null.

Насчет вреда от cascade update и самому будет интересно узнать

Answer 4

[alexalexes]

1. Коротко. Если придерживаетесь строгой концепции разработки хранения "база помнит всё", то никаких каскадных обновлений быть не должно. Должны оставаться следы связности записей, изменение внешних ключей должно быть регулировано бизнес-логикой. Если же вы разрабатываете структуру базы под сохранение текущего состояния данных, то можете использовать каскадное обновление, вам оно будет в помощь.
2. Когда внешний ключ может не использоваться при определенном сочетании данных в записи таблицы.