мягкое удаление общих атрибутов в отношении каскадного восстановления

Какие типы полей обычно используются для мягкого удаления? Что-нибудь из этого, какие-нибудь другие?

bool IsDeleted // nice because the default value is 0 (no) just in case
date DateDeleted // is this a common one?
date DateCreated // more of a temporal db aspect
date DateModified // same with respect to created

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

The trick is cascade restoring. При каскадном удалении со сценарием мягкого удаления все записи в реляционном графе помечаются как удаленные, неактивные, независимо от флага, возможно, разница состоит в том, чтобы изменить значение datedeleted на значение с нуля. При каскадном восстановлении ссылки на записи должны быть оценены, чтобы увидеть, была ли причина, по которой они были удалены, результатом каскадного удаления, связанного с восстанавливаемой, реактивируемой или восстановленной записью.

Как выполняются операции каскадного восстановления сохраненных данных?


soft-delete database-design rdbms cascade theory
person Travis J    schedule 10.04.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Таблица журнала транзакций обычно имеет такие столбцы, как: дата / время события, характер события (вставка, обновление, удаление, ...), а также пользователь и / или процесс, выполнивший действие. Также существует связь между журналом транзакций и затронутой записью в базовой таблице. Это можно сделать с помощью внешнего ключа в базовой таблице для таблицы журнала транзакций, но чаще всего журнал транзакций содержит внешний ключ для базовой таблицы. Если таблица журнала транзакций является общей для различных базовых таблиц, вам понадобится индикатор базовой таблицы плюс внешний ключ базовой таблицы.

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

person Joel Brown    schedule 11.04.2012
comment
Главный вопрос - восстановление. Удаление довольно просто. Но при восстановлении в обратной каскадной манере трудно сказать, возможно ли, что, хотя каскадный граф может быть восстановлен, зависимости этого графа уже могли быть удалены, в то время как восстанавливаемый граф был помечен как неактивный. - person Travis J; 11.04.2012
comment
См. Этот вопрос для получения более подробного вопроса о восстановлении: stackoverflow.com/q/10111699/1026459 - person Travis J; 11.04.2012
comment
@TravisJ - в своем ответе я указал, что мое рекомендуемое решение для таблиц журнала транзакций включает идентификатор бизнес-транзакции, который играет важную роль в выяснении того, что было каскадировано. Найдя все изменения с одним и тем же идентификатором бизнес-транзакции, вы найдете все шаги, которые были выполнены во время удаления. Чтобы выполнить восстановление, выполните эти шаги в обратном порядке. Единственная возможная проблема, с которой вы можете столкнуться, заключается в том, что элементы, удаленные каскадом, каким-то образом также имеют дополнительные зависимости, которые могли быть мягко удалены в другое время под другим идентификатором бизнес-транзакции. Это должно быть редкостью. - person Joel Brown; 11.04.2012