[magicalhippo]

That is a possibility. But all our "soft-delete targets" have at least 2-3 levels of child tables, it's never just one table. So that complicates matters.

For example, it could be the user deletes a customer entry in our system, the customer has contacts, and each contact has multiple contact methods say. There are many other child tables for a customer, like delivery addresses and official id numbers and so on, this was just an example.

And yes, user wants to use this data as before it was deleted. So has to go back into the same tables.

On the bright side, we don't have too many foreign keys to "associated data". For example, orders with that customer id would not change, just point to a non-existing customer. So after restore that all works fine.

[yau8edq12i]

Why give the possibility to the user of deleting a customer, in that situation? Having orders pointing to inexistant customers sounds rough.

[magicalhippo]

Quite a lot of our clients find large lists/tables inelegant, confusing or otherwise annoying. They like to have them neat and tidy.

There's also GDRP, they can register persons as a customer and get requested to delete data, so they need to have the ability to actually delete.

But mostly the reason is legacy. Just quicker and easier to delete from database than implement a decent soft-delete.