Это плохо для доверия расположению каскадом внешнего ключа?
Ведущий разработчик на проекте, в который я вовлечен, говорит, что это - плохая практика для доверия каскадам для удаления связанных строк.
Я не вижу, как это плохо, но я хотел бы знать Ваши мысли о том, если/почему это.
4 ответа
Вначале я скажу, что я редко удаляю строки , период . Как правило, вы хотите сохранить большую часть данных. Вы просто помечаете его как удаленный, чтобы он не показывался пользователям (т.е. им он казался удаленным). Конечно, это зависит от данных и некоторых вещей (например, содержимого корзины покупок). Фактическое удаление записей, когда пользователь опустошает свою корзину, вполне нормально.
Я могу только предположить, что проблема здесь в том, что вы можете непреднамеренно удалить записи, которые на самом деле не хотите удалять. Однако ссылочная целостность должна предотвратить это. Так что я не вижу причин против этого, кроме как явного.
Я никогда не использую каскадное удаление. Почему? Потому что ошибиться очень легко. Намного безопаснее требовать от клиентских приложений явного удаления (и выполнения условий удаления, таких как удаление записей, относящихся к FK).
Фактически, удаления как такового можно избежать, пометив записи как удаленные или перемещаемые. в архивные / исторические таблицы.
В случае пометки записей как удаленных, это зависит от относительной доли помеченных как удаленных данных, поскольку SELECT s должны будут фильтровать ' isDeleted = false ' и index будет использоваться только в том случае, если менее 10% (приблизительно, в зависимости от СУБД) записей помечены как удаленные.
Какой из этих двух сценариев вы бы предпочли:
1) Разработчик приходит к вам и говорит: «Эй, это удаление не сработает». Вы оба изучаете его и обнаруживаете, что он случайно пытался удалить все содержимое таблицы. Вы оба смеетесь и возвращаетесь к тому, что делали.
2) Разработчик подходит к вам и робко спрашивает: «У нас есть резервные копии?»
Еще одна важная причина избегать каскадных удалений - это производительность. Они кажутся хорошей идеей до тех пор, пока вам не понадобится удалить 10 000 записей из основной таблицы, которая, в свою очередь, имеет миллионы записей в дочерних таблицах. Учитывая размер этого удаления, он, вероятно, полностью заблокирует всю таблицу на часы, а то и дни. Зачем тебе рисковать этим? Для удобства тратить на десять минут меньше времени на написание дополнительных операторов удаления для удаления одной записи?
Кроме того, ошибка, возникающая при попытке удалить запись, имеющую дочернюю запись, часто бывает полезной. Он говорит вам, что вы не хотите удалять эту запись, потому что есть данные, которые вам нужны, которые вы потеряете, если бы вы это сделали. Каскадное удаление просто продолжит и удалит дочерние записи, что приведет к потере информации о заказах, например, если вы удалите клиента, у которого были заказы в прошлом. Подобные вещи могут полностью испортить ваши финансовые отчеты.
Я бы сказал, что вы следуете принципу наименьшего удивления.
Каскадное удаление не должно приводить к непредвиденной потере данных. Если удаление требует удаления связанных записей, и пользователь должен знать, что эти записи будут удалены, то каскадное удаление использовать не следует. Вместо этого от пользователя следует потребовать явным образом удалить связанные записи или предоставить уведомление.
С другой стороны, если таблица относится к другой таблице, которая носит временный характер или содержит записи, которые никогда не понадобятся после исчезновения родительского объекта, то каскадное удаление может быть допустимым.
Тем не менее, я предпочитаю заявить о своих намерениях явно путем удаления связанных записей в коде, а не полагаться на каскадные удаления. Фактически, я никогда не использовал каскадное удаление для неявного удаления связанных записей. Кроме того, я часто использую мягкое удаление, как описано cletus.