Как залогировать каскадное удаление?

Question

[Turtle_Onni]

Всем привет!

Во время удаления данных из кода - эта транзакция фиксируется, но в в базе происходит еще и каскадное удаление. Как зафиксировать и последующие транзакции удаления данных во время каскадного удаления в базе?

Большое спасибо заранее.

Answer 1

[Александр Кузнецов]

Где Вы хотите это фиксировать?

Каскадное удаление происходит, как известно, за счет того, что у ваших внешних ключей стоит ON DELETE CASCADE. На мой взгляд, тут лучше ON DELETE NO ACTION, что заставит Вас руками удалять предварительно все связанные данные, которые ссылаются на удаляемый объект, что как раз и приведет Вас у полному контролю процесса удаления с фиксацией транзакций, с записью контекстной информации и т.п.

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

Comments

[d-stream]

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

Не всегда и не везде.

Зачастую маркированные "удаленными" записи могут оказаться вредными. К примеру любая связка M:N - в оригинальном варианте таблица-связка состоит из пары колонок (pkN и pkM) с первичным ключом из этой пары. Если вдруг заморочиться маркировкой - придется добавлять третью колонку признака удаленности, делать третьей составляющей pk и потом огребать счастье в виде создание-удаление-создание....

Да и не надо это бизнесу на этом уровне - ему надо чтобы все ходы были записаны = логгирование добавления и удаления записи в связку. Притом в "переводе" на язык бизнеса. Например если связка это доступ сотрудников к складам (умышленно упускаю еще и уровни доступа и вытекающий оттуда update ) - то insert в связку повлечет за собой пару записей в бизнес-понимаемые логи (лог склада - "добавлен доступ сотрудника ФИО" и лог сотрудника - "добавлен доступ к складу хХХ")

[Evgeny Maltsev]

d-stream, соглашусь с ответом Александр Кузнецов. Каскадное удаление мы не можем отследить на уровне приложения.

spoiler

На ум вообще приходит один способ, но назвать его нормальным язык не поворачивается. Если мы используем EntityFramework в качестве ORM, то перед удалением можем пробежаться по всем таблицам DbContext'a, вычислить все FK, связанные с таблицей, из которой удаляется строка. Сделать по этим FK запросы, сохранить всю нужную инфу от связанных таблиц. Наконец, удалить строку. Если удаление прошло успешно, то пишем лог с ранее сохранённой инфой.

Соответственно, это делает практику каскадных удалений неприменимой к таблицам, требующих логирования.
Насчет "вредности" поля IsDeleted. Практика показывает, что лучше всего вообще не использовать в дизайне базы данных натуральные ключи (комбинации каких-то столбцов, их частей и т.д.), а использовать суррогатные (например, поле id с автоинкрементом). Используя натуральные ключи, какую цель мы преследуем? Зачастую это перекладывание бизнес-логики на уровень базы данных. В моём понимании бизнес-логика должна быть на уровне приложения. То есть мы не хотим добавлять новую строку, а потом отлавливать ошибку бд из-за того, что строка с таким ключом уже существует. Просто перед добавлением мы сами должны делать проверку и если в базе уже есть такая строка, то сообщить пользователю. Это часть нашей бизнес-логики.
Также уникальность (identity) строки с натуральным ключом может быть легко нарушена путем изменения одного из столбцов ключа. Это может быть проблемой в будущем. С айдишником такой проблемы не возникнет.
Таким образом, если мы отключаем каскадное удаление, используем натуральные ключи и у нас всё в порядке с бизнес-логикой, то поле IsDeleted хороший паттерн.
P.S. Мартин Фаулер в "Шаблонах" пишет о том, что нужно всегда избегать натуральных ключей.