Я обычно опасаюсь каскадного удаления (и других автоматических действий, которые могут сбрасывать / повреждать данные), либо с помощью триггеров, либо ON <something> CASCADE. Такие объекты очень мощные, но также потенциально опасные.
- Итак, является ли каскадное удаление правильным выбором здесь?
Он, безусловно, будет делать то, что вы ищете: удалять связанные записи при удалении родительской записи, без необходимости реализовывать какую-либо другую логику, чтобы гарантировать, что дочерние элементы будут удалены первыми, что сделает ваш код более кратким. Все действия будут заключены в неявную транзакцию, поэтому, если что-то блокирует дочерний объект, удаляется вся операция, блокируется, поддержание ссылочной целостности с небольшими или никакими дополнительными усилиями по кодированию.
Убедитесь, что ваше использование каскадных удалений и других «закулисных» действий хорошо задокументировано, чтобы будущие сопровождающие системы были полностью осведомлены об этом.
- Когда не следует использовать каскадный детектор?
Это не должно использоваться, если вы параноик, как я! Одним из ключевых моментов, которые следует учитывать, являются другие разработчики, которые в настоящее время или могут в будущем работать над вашим кодом / базой данных (отсюда и комментарий выше о документировании любых «скрытых» действий).
По моему опыту, неопытные люди часто используют DELETEзатем повторно INSERTдля обновления строк, особенно когда они действительно хотят выполнить операцию MERGE/ UPSERT(обновить существующие строки и создать новые там, где строки с данным ключом не существует) и СУБД не поддерживает слияние / вставку (или они не знают о ее поддержке). Без каскадных действий это совершенно безопасно (или приведет к ошибке, когда это угрожает целостности данных), но если кто-то сделает это для строк в родительской таблице, где ссылающиеся FK имеютON DELETE CASCADEустановить затем связанные данные будут удалены в результате первоначального удаления и не будут заменены - поэтому данные будут потеряны (не то, что даже если удаление и последующая вставка заключены в явные транзакции, каскад происходит с операцией удаления - он не будет подождите, чтобы увидеть, заменяет ли транзакция строки в родительской таблице в последующих операторах), и каскад может продолжаться через другие корабли отношений (например: удалить старшего супервизора, его команда удаляется каскадом, команды его команд удаляются каскадом, все отслеживаемые записи всех этих людей удаляются каскадом, ...). Без включенного каскадирования вы бы просто получили ошибку, а не потеряли данные.