One of the most common reasons to “mark a record as deleted” rather than deleting it is so you can undo deletes without having to fish data out of a backup. I.e. soft delete is effectively a recycle bin. It might not be a user-facing recycle bin, but it’s a recycle bin nonetheless.
The way it was overlooked by me is because a ‘bin’ is something you clear regularly, but deleted records will likely persist forever.
That being said; I once helped out a friend who’s computer became slow to a crawl, only to find out they’d never emptied their bin so storage had only a few GB of free space left.
> The way it was overlooked by me is because a ‘bin’ is something you clear regularly, but deleted records will likely persist forever.
Clear regularly, but usually also has the option to undo. The article sort of suggests something similar to clearing regularly.
> So you may eventually find yourself writing a hard deletion process which looks at soft deleted records beyond a certain horizon and permanently deletes them from the database.
Another other reason to do soft-deletes up front, then hard delete later is because in some DBs (eg: OLAP), deletes can be extremely expensive. It's sometimes better to soft-delete (or invalidate references), and handle the hard-deletes in a batch-oriented manner on a regular basis.