Какова проблема с каскадными разнообразными путями внешнего ключа и циклами?
Вне стандартное определение можно добраться от Википедия . Я нахожу, что это большой инструмент для соединения набора унаследованных систем через несколько платформ и технологий. Это - также польза инструменты для создания распределенных рабочих процессов и систем управления состоянием (таких как главная бухгалтерская книга).
Однако это довольно дорого, сложно и неудобно, чтобы поддержать и расшириться, который делает это плохим технологическим выбором как инструмент общего назначения для масштабирования Вас приложения.
4 ответа
У вас есть дочерняя таблица с двумя каскадными путями от одного и того же родителя: один «удалить», один «ноль».
Что имеет приоритет? Чего ты ждешь потом? и т. д.
Примечание: триггер - это код, который может добавить некоторый интеллект или условия в каскад.
Рассмотрим таблицу сотрудников:
CREATE TABLE Employee
(
EmpID INTEGER NOT NULL PRIMARY KEY,
Name VARCHAR(40) NOT NULL,
MgrID INTEGER NOT NULL REFERENCES Employee(EmpID) ON DELETE CASCADE
);
INSERT INTO Employees( 1, "Bill", 1);
INSERT INTO Employees( 23, "Steve", 1);
INSERT INTO Employees(234212, "Helen", 23);
Теперь предположим, что Билл уходит на пенсию:
DELETE FROM Employees WHERE Name = "Bill";
Ooooppps; всех просто уволили!
[ Мы можем спорить, верны ли детали синтаксиса; концепция остается в силе, я думаю. ]
Я согласен с тем, что каскады "опасны" и их следует избегать. (Я лично предпочитаю каскадировать изменения вручную, вместо того, чтобы о них позаботился сервер sql). Это также связано с тем, что даже если сервер sql удалил миллионы строк, результат все равно будет отображаться как
(затронута 1 строка (строки))
Причина, по которой мы запрещаем использование каскадного удаления, связана с производительностью и блокировкой. Да, это не так уж плохо, когда вы удаляете одну запись, но рано или поздно вам нужно будет удалить большую группу записей, и ваша база данных остановится.
Если вы удаляете достаточно записей, SQL Server может перейти к блокировке таблицы, и никто не сможет ничего сделать с таблицей, пока она не будет завершена.
Недавно мы переместили одного из наших клиентов на его собственный сервер. В рамках сделки нам также пришлось удалить все записи этого клиента с нашего исходного сервера. Удаление всей его информации партиями (чтобы не доставлять проблем другим пользователям) заняло пару месяцев. Если бы у нас было настроено каскадное удаление, база данных была бы недоступна для других клиентов в течение длительного времени, поскольку миллионы записей были удалены за одну транзакцию, а сотни таблиц были заблокированы до завершения транзакции.
Я также мог видеть сценарий, в котором могла возникнуть тупиковая ситуация при использовании каскадного удаления, потому что мы не можем контролировать порядок, в котором проходил бы каскадный путь, а наша база данных несколько денормализована, и в большинстве таблиц появляются клиентские данные. Поэтому, если он заблокировал одну таблицу с внешним ключом также для третьей таблицы, а также клиентскую таблицу, которая находилась на другом пути, он, возможно, не смог бы проверить эту таблицу, чтобы удалить из третьей таблицы, потому что это все одна транзакция, и блокировки не будут сняты, пока она не будет выполнена. Так что, возможно, это не так Они позволили нам настроить каскадное удаление, если увидели возможность создания взаимоблокировок в транзакции.
Еще одна причина избегать каскадных удалений заключается в том, что иногда наличие дочерней записи является достаточной причиной, чтобы не удалять родительскую запись. Например, если у вас есть таблица клиентов и у этого клиента были заказы в прошлом, вы не захотите удалить его и потерять информацию о фактическом заказе.