Обработка удаления записей базы данных с несколькими уровнями потомства

Question

У нас есть база данных, которая обычно имеет такую ​​структуру:

Master Record Table
id (pk)
MasterRecordId <-- constrained to be unique

Дети / братья и сестры (2-го поколения, если хотите):

Table1
(  table1ID (pk),
  MasterRecordID (fk))

Table2
(  Table2ID(pk),
  MasterRecordID (fk))

Внуки (3-го поколения):

Table3
( Table3ID (pk)
 Table1ID (fk))

Table4
 (Table4ID (pk)
  Table1ID (fk))

Table5
 (Table5ID (pk)
  Table2ID (fk))

Не на каждом столе второго поколения есть дети. Функция ограниченного удаления в приложении (вы можете удалить любую отдельную запись, но FKs будут предотвращать удаление во многих случаях; функциональность удаления прерывается и изящно не ошибается).

Мне было поручено исследовать лучший способ обработки удаления. Для очистки всей записи от Мастера до внучатых детей бэкэнд - единственный способ сделать это. Это сделало силы, которые будут счастливы. Но, вы знаете, пользователи лгут, и получается, что нам, возможно, придется изменить это (и то, и другое, поэтому мне не нужно время от времени служить Официальным средством удаления записей, и поскольку есть определенные типы записей Gen 2, которые пользователи удаляют часто .

Каскадное удаление было первым вариантом, поскольку TPTB предпочел бы, чтобы это не требовало работы над новой сборкой приложения. И потому, что это то, что выскочило из уст моих боссов в конце этой конкретной встречи. Мои каскады Gen 2 -> Gen 3 работают нормально (и это касается наиболее частого варианта использования / истории / что у вас). Затем я обновил все внешние ключи Master -> Gen 2 для каскадного удаления. В надеялись , что это позволило бы удалить основную запись, и что все другие дети и внуки пойдут с ней. Не хорошо; Я получаю сообщение об ошибке, нарушающее первый Мастер -> Gen 2 FK, который появляется, когда я пытаюсь удалить основную запись. Я дважды проверил; ФК установлены на каскад при удалении.

Что я не понимаю о каскадных удалениях с более чем одним уровнем табличных отношений? Я читаю столько, сколько могу (насколько позволяет время), но я еще не обнаружил знаний, которые выведут меня из этого темного времени. Каскадный подход неправильный?

Во-вторых, у меня есть два других варианта:

1. Делать все удаления в приложении. Не предпочтительно, но если это единственный вариант, это единственный вариант. Я знаю, что есть аргументы, что это лучший вариант, но у TPTB разные взгляды на лучшее, чем у меня (и хотя они все сумасшедшие, они подписывают чеки).

2. Ручка удаляется через триггер? Мне неясно, доберутся ли до этого Foreign Keys, но мне пришло в голову, что это может быть вариант.

Ну и еще:

3. У каскада Gen 2 -> Gen 3. И тогда нескольким людям с разрешениями на удаление нужно будет просто следовать ритуалам, чтобы выполнить полное удаление (то есть: удалить все записи Gen 2 по отдельности, затем удалить мастер). Или я застряну как Официальный Уничтожитель Отчетов.

Answer 1

Итак, по-видимому, у меня было что-то не так с одним или несколькими моими отношениями (удаление на бэкэнде сделало это более понятным). Я поставил свежую копию БД и заново применил свои сценарии, и теперь все работает. Эта статья в MSDN помогла мне понять, что проблема должна быть в одном из моих отношений. И было полезно в целом.

Итак, посмотрим, что TPTB решит, что мне делать дальше.

Answer 2

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

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

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