[FriedrichN]

I have seen so many people argue against soft deletes over the years. But I have also had so many instances where users 'accidentally' deleted a bunch of items and then call support to ask if there are any backups. And then I'll have to reconstruct the data from yesterday's backup plus today's changes. A soft delete will take care of this.

And no amount of "are you really really really sure you want to delete this?" confirmations are going to fix this. You could require the whole Spongebob Squarepants ravioli ravioli give me the formuoli song and dance and people will still delete hundreds or thousands of records by accident.

[philprx]

On this case, one way is to make a past_ or deleted_$tablename where you insert the deleted row before deleting it from production table.

This way you can watch post mortem, restore etc...

AND it's not soft delete since the data is really gone from the production table, therefore no query tweaking

Only thing: you need to really delete when GDPR related deletion is requested.

[FriedrichN]

>On this case, one way is to make a past_ or deleted_$tablename where you insert the deleted row before deleting it from production table.

The problem with this that it gets really cumbersome if you have a complex system of tables that depend on the main table, you'll end up having to make deleted/archived versions of all those tables. In that case it's easier to have a deleted/archived flag in the main table.