I can think of one possible solution: - Soft deleted rows should be moved to a shadow table, so that they can have their own unique ID and timestamp fields. - W

I can think of one possible solution: - Soft deleted rows should be moved to a shadow table, so that they can have their own unique ID and timestamp fields. - What's the column name and type of? - Well, you'd have to extend SQL, but that's done regularly. DELETE (PERMANENTLY | AS MOVE TO SHADOW) with permanently the default. - Not a good idea to update a soft deleted row, I'd prevent it with roles if possible. - No, because the shadow table has its own primary key, and shouldn't have any unique constraints on it because of this design.