Каскад на Удаляет или использует Триггеры?
Ну, это законно:
shared_ptr<Foo> foo; /* don't assign */
И в этом состоянии, это ни на что не указывает. Можно даже протестировать это свойство:
if (foo) {
// it points to something
} else {
// no it doesn't
}
Итак, почему бы не это:
std::vector < shared_ptr<Foo> > vec;
vec.push_back (shared_ptr<Foo>); // push an unassigned one
4 ответа
КАСКАДНОЕ УДАЛЕНИЕ на сервере MSSQL может выполняться только каскадно в одну таблицу. Если у вас есть две таблицы со связями внешнего ключа с таблицей измерения, вы можете каскадно удалить только одну из них. (Это сделано для предотвращения каскадных удалений по нескольким путям и создания конфликтов, так же как C ++ допускает множественное наследование, а C # допускает только одиночное наследование)
В этом случае вы вынуждены использовать триггеры или специально обрабатывать случай в своем коде
По этой причине я видел, как многие люди выбирают триггеры во всех случаях. Даже когда есть только один сторонний стол. Это обеспечивает согласованность, и люди знают, на что обращать внимание при обслуживании базы данных.
Если бы можно было каскадировать удаление более чем одной таблицы, я бы сказал, что это будет наиболее предпочтительный вариант. Однако это ограничение мутит воду, и в настоящее время я больше поддерживаю триггеры, обладающие всем таким поведением. Накладные расходы при использовании триггеров для каскадных удалений и обновлений незначительны с точки зрения кодирования, но допускают стандартные методы, которые действительно являются общими.
РЕДАКТИРОВАТЬ:
Вы можете захотеть переместить «принятый ответ» кому-то другому. , Я выяснил, что ошибался в вышеизложенном.
Вы МОЖЕТЕ иметь несколько таблиц фактов, у которых есть ограничения внешнего ключа ON DELETE CASCADE для единственной таблицы измерений.
Что вы не можете сделать, так это иметь одну таблицу фактов. иметь ON DELETE CASCADE ограничения внешнего ключа для нескольких таблиц измерений.
Так, например ...
- Таблица измерений [Человек] (id INT IDENTITY,)
- Таблица измерений [Экзамен] (id INT IDENTITY,)
- Таблица лиц [Exam_Score] (person_id INT, exc_id INT, score INT)
Если удаляются либо человек, либо экзамен, вы хотите, чтобы связанные записи Exam_Score также были удалены.
Это невозможно использовать ON DELETE CASCADE в MS SQL Server, поэтому необходимы триггеры.
(Извинения Мехрдаду, который пытался мне это объяснить, но я полностью упустил его точку зрения.)
Я почти согласен с Демсом здесь, за исключением того, что использую ON DELETE CASCADE (и ON UPDATE CASCADE в этом отношении) ссылочные действия везде, где это возможно, и только прибегаю к помощи использовать триггеры там, где это необходимо. Я бы также рассмотрел вопрос об отзыве разрешений для таблиц и принудительном использовании «вспомогательных» хранимых процедур для удалений и обновлений.
Назовите меня оптимистом, но я верю: а) мой код переживет перенос на будущую версию MS SQL Server и б) команда SQL Server в один прекрасный день решит исправить ограничение «один каскадный путь», после чего я заменю триггеры каскадными ссылочными действиями :)
Держитесь подальше от ненужных триггеров.
Используйте ON DELETE CASCADE , если это все, что вам нужно сделать.
Я бы использовал каскад при удалении, но это только в том случае, если вы определенно хотите удалить дочерний элемент, если родительский элемент удален.
Если у вас есть условная логика (я удаляю только дочерний элемент если удалено в воскресенье), используйте триггер.
Я бы просто изменил его на каскад при удалении в системе разработки, затем запустил свои модульные тесты и убедился, что ничего не сломается.