soft delete common attributes with regards to cascade recovery

Question

What type of fields are generally used to accompany soft delete? Any of these, any others?

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 reason I ask is that when using soft-deletes, cascading must still be implemented in order to maintain integrity. However, the real trick is not cascade deleting, which is rather easy.

The trick is cascade restoring. On cascade delete, with a soft-delete scenario, all records in the relational graph are flagged as deleted, inactive, whatever the flag is, perhaps the difference is to change the datedeleted to a value from null. On cascade restore, record references must be evaluated to see if the reason they were deleted was a result of a cascade delete related to the record being restored, reactiviated, undeleted.

How are cascade restore operations handled with regards to stored data?

Answer 1

In a case where you want to track not only the results of what has happened, but also when it happened and why, people often use a transaction log.

A transaction log table typically has columns such as: date/time of the event, nature of the event (insert, update, delete,...), and the user and/or process that performed the action. There is also a link between the transaction log and the affected record in the base table. This can be done with a foreign key on the base table to the transaction log table, but it is more common to have the transaction log contain a foreign key to the base table. If the transaction log table is shared amongst various base tables, you'd need a base table indicator plus a base table foreign key.

In your case, if deletions are the main concern, you could restrict log entries to deletions and make a distinction between a cascade delete vs. other deletes. You could (should) also consider using transaction wrappers to write all of the soft deletes (primary plus cascading) at one time. You can include some kind of identifier, like an identity value or a GUID as a "business transaction ID" in your log and place this ID into every entry that is part of the same operation. This gives you a clear indication of what happened, when it happened, why it happened, and which records it happened to. You'll be able to use this information to decide how to reverse any particular transaction, including performing a cascade restore.