Использование каскадных операторов в ограничениях внешнего ключа является горячей темой.
Теоретически, если вы точно знаете, что удаление родительского объекта автоматически будет означать также удаление всех его дочерних объектов, то может иметь смысл каскадное удаление по ссылке между дочерней и родительской таблицами.
Представьте себе «машину», состоящую из «частей». Если ваша логика гласит, что если машина удаляется, все части, составляющие эту машину, также должны быть удалены из базы данных, то вы можете использовать опцию каскадного удаления в ссылке внешнего ключа между таблицей деталей и таблицей машины.
Однако: это может быть немного сложно, особенно если у вас есть целая цепочка таблиц, связанных с этим параметром. Поэтому многие разработчики предпочитают обрабатывать это в своем собственном коде доступа к данным, а не определять его в базе данных.
Каскад обновления обычно используется при изменении первичного ключа родительской таблицы - чтобы обновить все связанные дочерние таблицы и строки, чтобы отразить это изменение. Обычно это воспринимается как запах кода базы данных - здесь лучше убедиться, что первичный ключ никогда не изменится, так что это каскадное обновление никогда не понадобится - например, введя в таблицу искусственный «суррогатный» ключевой столбец, который не имеет делового значения и поэтому никогда не обновляется.
Помогает ли это вообще? Какая-то конкретная деталь, о которой вы все еще неясны?
Мое мнение таково: хотя теоретически это отличная идея, большинство разработчиков на самом деле не используют это в режиме реального времени - большинство разработчиков решат использовать это в коде доступа к данным, что дает им полный и явный контроль. над тем, что удаляется (или обновляется).