Какие проблемы могут быть с внешними ключами RESTRICT?

Question

[Arman]

1. На github посмотрел миграции разных проектов и в основном ставят CASCADE и иногда SET NULL. Очень редко встречается RESTRICT, при этом ставят связи на первичные ключи, поля которые наверно никогда не меняются. Вся логика связей у меня в приложении, для подстраховки решил поставить и внешние ключи, но вот не вижу смысле на первичные ключи ставить CASCADE, думаю большие шансы что кто-то случайно (через PMA и т.д.) пытается поменять это значение, и мне лишь надо ему отказать в этом. Или это не так?

2. Есть ли смысл ставить внешние ключи на опциональные поля, например, id-пользователя который обновил/создал запись и т.д.

3. При миграциях есть смысл блокировать таблицы? Или транзакции должно хватить?

Answer 1

[Melkij]

restrict по стандарту sql дефолтный. И самый оптимальный для задачи "мешать делать глупости".
FK надо ставить на все связи. Если только чётко и аргументированно не доказано обратное для каждого конкретного случая в отдельности.

При миграциях есть смысл блокировать таблицы? Или транзакции должно хватить?

Mysql? Все DDL не только не транзакционные, а ещё и вызывают неявный коммит.
Нужно ли явно блокировать таблицы - зависит от того, что вы собираетесь сделать. Обычно задача стоит как внести изменение, не затрагивая прод.