This article confirms my biases because I’ve always despised every soft delete implementation I’ve come up with. Most of them have looked something like what the author describes:
the technique has some major downsides. The first is that soft deletion logic bleeds out into all parts of your code. All our selects look something like this:
SELECT *
FROM customer
WHERE id = @id
AND deleted_at IS NULL;
And forgetting that extra predicate on deleted_at can have dangerous consequences as it accidentally returns data that’s no longer meant to be seen.
ORMs help with this, but not enough. You set it as a default scope and then there’s that one time where you also want the deleted records so you come up with a custom query or dig into your ORM and try to find how to bypass the rule. Yuck!
He goes on to describe other problems as well. Maybe it’s all a big case of YAGNI?
Once again, soft deletion is theoretically a hedge against accidental data loss. As a last argument against it, I’d ask you to consider, realistically, whether undeletion is something that’s ever actually done.
When I worked at Heroku, we used soft deletion.
When I worked at Stripe, we used soft deletion.
At my job right now, we use soft deletion.
As far as I’m aware, never once, in ten plus years, did anyone at any of these places ever actually use soft deletion to undelete something.
