DELETE Trigger vs Stored Процедура для удаления зависимых строк

Question

Я видел разные посты о том, как реализовать удаление зависимых строк из других таблиц с помощью CASCADE DELETE или различных способов создания или поиска зависимостей и создания динамического SQL.

Я не в восторге от идеи использования CASCADE delete, если только по причинам, связанным с чрезмерным заголовком, из-за того, что CASCADE выдает так много DELETE для записей, которые имеют многочисленные зависимости, которые имеют свои собственные многочисленные зависимости (не упомянуть тот факт, что результаты могут быть трудно отследить и не все, что хорошо подходит для производственных сред).

Итак, смирившись с тем, что написал их тем или иным способом, мне интересно, каков компромисс с размещением всех необходимых удалений в хранимой процедуре или триггере удаления.

Мне нравится опция триггера DELETE, потому что она сохраняет семантику удаления прямо. То есть:

DELETE FROM [SomeTable] WHERE [SomeColumn] = VAL

Позаботится обо всем удалении, о котором нужно позаботиться, и ни один разработчик не может ошибиться, не вызвав процедуру удаления:

EXECUTE [prc_SomeTable_Delete] VAL

Тем не менее, меня беспокоит использование TRIGGER, поскольку мне кажется, что я вижу довольно много «экспертных» рекомендаций против их [частого] использования.

С моей точки зрения, фактическая реализация TRIGGER по сравнению с хранимой процедурой кажется почти идентичной. Таким образом, при условии, что мы применяем последовательную практику, кажется, что решение TRIGGER должно работать нормально.

Существует ли лучшая [или самая распространенная] практика, которой следует следовать? Какими должны быть мои опасения в краткосрочной и долгосрочной перспективе? По большей части эти удаления будут производиться из клиентского приложения .NET - скорее всего, полагаясь на Entity Framework для доступа к данным и манипулирования ими; как это должно повлиять на мое решение?

Не стесняйтесь размещать ссылки на исчерпывающие соображения по этой теме, поскольку мои усилия еще не дали никаких результатов.

Спасибо всем.

Answer 1

Триггеры имеют явный недостаток: они запускаются сразу, и вы не можете отложить их выполнение.При интенсивном использовании ваша система может быть настолько занята выполнением всех этих триггеров, что она остановится.

Если вы можете сделать что-то вроде:

• сделайте «заметку»в таблице, зависимые строки которой необходимо удалить
• запланируйте задачу очистки, которая выполняет свою работу в непиковые часы, например, ночью

ваша общая производительность системы должна быть очень высокойлучше.Для этого, однако, требуется, чтобы вы могли ждать некоторое время между моментом удаления «родительских» строк, пока вы фактически не удалите зависимые дочерние строки.

Но, как вы говорите -написанный код почти такой же, так что вы могли бы сначала использовать триггер и посмотреть, как он себя ведет и как он влияет на производительность вашей системы.Если это становится слишком тяжелым в вашей системе, «отсоедините» эти события (родительская строка удаляется, а зависимые дочерние строки удаляются), используя такую ​​«асинхронную» модель с сохраненным процессом, вызываемым с заданными интервалами для выполненияуборка.

Answer 2

Нет ничего плохого в соответствующих триггерах. Люди, которые против них, часто испытывали неудачу из-за того, что они были плохо написаны или потому, что их разработчики были слишком некомпетентны, чтобы думать, что что-то может произойти в триггере.

В этом случае я бы не стал выполнять эту задачу в триггере. Причина по той же причине, по которой вы не хотите делать это с помощью каскадного удаления. Если кто-то удаляет то, что имеет миллион дочерних записей, вы заперли вещи.

Удаление происходит не только из интерфейса, но в этом случае я предпочитаю подход с сохраненным процессом, потому что вы можете использовать его для удаления записей с обычным количеством записей и если кому-то нужно удалить миллионы записей в специальном запросе затем они могут написать код для удаления, используя пакетную обработку, а не все сразу.

Также любой, кто пытается удалить вручную (например, для дедупликации или перемещения данных клиента в другую базу данных), получит ошибки, если есть дочерние записи, что, на мой взгляд, хорошо, потому что это делает их подумайте, следует ли удалить запись. Например, если вы удаляете кучу повторяющихся записей, вы, возможно, не захотите делить их заказы, а скорее переместить их другому клиенту (запись, которую вы сохраняете). Таким образом, если ваш процесс сталкивается с ограничением FK, вы знаете, что у вашей дедуплицирующей порцессы есть проблема, и вы можете ее исправить. И иногда эти ошибки FK являются просто подсказкой, которую вы не хотите удалять. Так что, может быть, вы можете исключить клиента и его таблицу адресов, но если вы нажмете таблицу заказов FK, вы не захотите удалять. Слишком легко производить автоматическое удаление, такое как каскадное удаление и срабатывание, когда вы забываете, что иногда ошибка FK говорит о том, что вы не должны удалять.