@MatveyGogolev

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

Здравствуйте, у меня есть 2 вопроса про реляционные БД:
1. Когда каскадное обновление это плохо?
2. Когда имеет смысл ставить null во внешнем ключе?
  • Вопрос задан
  • 101 просмотр
Пригласить эксперта
Ответы на вопрос 4
@Akina
Сетевой и системный админ, SQL-программист.
Когда каскадное обновление это плохо?

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

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

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

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

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

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

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

Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.
Ответ написан
Комментировать
AshBlade
@AshBlade
Просто хочу быть счастливым
1. Когда сильно влияет на производительность
2. Когда ни на кого не ссылается
Ответ написан
Комментировать
delphinpro
@delphinpro
frontend developer
Второе очевидно - когда запись не имеет жесткой привязки и должна сохранится при удалении связанной (это про cascade delete), то связь следует выставить в null.

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

Войдите, чтобы написать ответ

Похожие вопросы