Здравствуйте, vaa, Вы писали:

vaa>Что по умолчанию обычно используете в ON UPDATE / ON DELETE?
vaa>Часто ли это обосновано явно ТТ или это ваш личный выбор на основе представления о модели?
On update не нужен, т.к. штатных ситуаций изменения первичного ключа не бывает.
On delete — тут два случая:
1. Речь идёт о ссылке на справочник. Тут однозначно никаких cascade, т.к. никто не ожидает при удалении какого-нибудь ненужного адреса дропнуть половину истории заказов.
2. Речь идёт о ссылке на владельца (типа ссылка на SalesOrder из OrderItem). Тут, в принципе, можно сделать и cascade, т.к. без хозяина подчинённая сущность смысла не имеет.
Но по большому счёту особого преимущества такая реализация не даёт, т.к. при реализации сценария удаления не так уж и сложно выписать предварительное удаление всех детей вручную.
Зато ручное указание даёт два важных преимущества:
— Маинтейнеру приложения не нужно гадать, какие ещё записи подвергнутся удалению. В частности, при поиске всех мест, из которых удаляются записи таблицы X, достаточно искать delete X, а не delete Y, где X транзитивно достижим из Y через on delete cascade.
— Порядок блокировок определяется не слепым случаем, а явно выписанным намерением программиста. Это означает, что у нас меньше риска, скажем, словить deadlock, когда один поток пытается добавить позицию как раз в ту корзинку, которую сейчас удаляет другой поток.