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.