Home/ Questions/Q 7801983
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T01:07:11+00:00

I am having some trouble formulating a solution for this foreseen situation. TableA has

  • 0

I am having some trouble formulating a solution for this foreseen situation.

TableA has a FK to TableB. TableC has a FK to TableA. TableC has a FK to TableD.

TableA
------
taId
tbId

TableB
------
tbId

TableC
------
tcId
taId
tdId

TableD
------
tdId

A brief series of events:

  • 1) A cascade soft-delete is issued to a record in TableB. This causes all related records in TableA to be soft-deleted, cascading to all related records in TableC being soft-deleted.
  • 2) At a later time, a record in TableD is soft-deleted, cascading again. This record in TableD was held as a FK in TableC. However, TableC was already marked as soft-deleted.
  • 3) The record in TableB in step 1 is requested to be restored.

    How can I make sure that when restoring the related records to the restored record in TableB (namely in TableA and TableC) that I do not restore any which had a dependency on the record from Step 2, TableD – moreover, that in not restoring parts which had a dependency on the record from Table D, I restrict restoration in a cascading manner (i.e. that TableA not be restored if TableC is found to have a relation to a soft-deleted record)?

    What I have considered is leveraging a temporal design in the tables along with a GUID. Each table would have (aside from a soft-delete flag) a DateDeleted field, and a GUID field (where the same GUID would be assigned to each node in a cascade soft-delete to distinguish the set of cascade). This would make it pretty easy to restore a cascaded set because they would share a date and a GUID. But the issue I came across, which is the one outlined above, was how to handle the situation where the soft-deleted records would have been removed from a different cascade.

    • Share

    Leave an answer

    You must login to add an answer.

    Need An Account,

    1 Answer

    1. Editorial Team

      Since your TableD record is soft-deleted, you don’t have to worry about breaking referential integrity by restoring your first soft cascade delete. However, what your cascade restore logic needs to do is to test the other dependencies of each table in which a soft-restore is being made.

      If there is a reference to a parent item which itself has been soft-deleted, then you need to do a soft-restore of that parent item too.

      A good way to achieve this is to have a per-table soft delete stored proc (or trigger) and a per-table soft restore stored proc (or trigger). These procs will take your date/GUID (soft delete business transaction ID) as input parameters.

      For each table, the procs in question will know what the dependencies are. The soft delete has downstream cascade dependencies and the soft-restore will have upstream cascade dependencies. Each proc will mark its own table’s record as deleted or restored and then call the procs necessary to perform the cascade actions.

      • 0