Нужно ли защищать данные в зависимых таблицах с помощью Foreign Key?
Например, есть две таблицы, в одной список чего-то (предок), в другой другой список (потомок), и одна колонка ссылается на первичных ключ предка. Если данные в первой таблице удалить, то вторая потеряет важную составляющую.
Можно (нужно) ли во всех подобных случаях, когда есть зависимости одного от другого прописывать FOREIGN KEY (RESTRICT). Хотя допускаю, что где-то можно использовать конструкции ON DELETE SET NULL, и тогда у потомка просто выставиться NULL, и данные будут болтаться (останутся не привязанными).
Когда это актуально, проще сделать отдельное поле предку, типа boolean -> del_status (ну или в таком духе). Ну и собственно ничего не удалять, а лишь исключать из выборки.
Либо писать запрос, который устроит массовы "Холокост" детям.
Иван т.е. однажды создав он останется в таблице, но будет иметь отдельный статус. По-идее если я хочу удалить - я хочу удалить, а не сместить в архив (скажем как в вордпрессе).
Остается вопрос открытым делать ли внешний ключ для защиты связи в первую очередь у потомка?
Bjornie: ВСЕ зависит от того, чего вы хотите добиться (а из вопроса не ясно). В общем случае FOREIGN KEY (RESTRICT) запретит Insert и Update по этим значениям, т.е. если я верно помню - вы не сможете удалить родителя.
Собственно вот вот что советует гугл.
В зависимости от желаемого нужен CASCADE или SET NULL.
Bjornie: Не совсем понятно какая у вас стоит цель. Вам нужна целостность данных или производительность? Приемлимо ли, что часть потомков осталась болтаться без родителя? Может вам вообще on delete cascade подойдет, чтобы потомки-сироты сами удалялись вслед за родителями.
