Easy, alternative soft deletion: `deleted_record_insert`
1–10 of 109 posts
Re: Easy, alternative soft deletion: `deleted_record_insert`
#2oh nice.
how do you recover deleted records?
Re: Easy, alternative soft deletion: `deleted_record_insert`
#3oh nice. how do you recover deleted records?
Exactly. The whole point of soft delete is data recovery, as it’s not sufficient for anything else (like auditing).
Re: Easy, alternative soft deletion: `deleted_record_insert`
#4oh nice. how do you recover deleted records?
It seems you should be able to do it fairly straightforwardly with dynamic sql with this structure, but, I don’t know why you wouldn’t just use proper history tables, rather than story only deleted records, but lumping them all into one table.
I’ve never encountered a database where I needed to know about non-current records but only ever the last-before-deletion state of deleted records, whether for data recovery or any other purpose.
Re: Easy, alternative soft deletion: `deleted_record_insert`
#5Reinventing standard database features like audit tables, sql server has such out of the box, same for any major databases.
Re: Easy, alternative soft deletion: `deleted_record_insert`
#6oh nice. how do you recover deleted records?
>and without the expectation that it’ll be used to undelete data (which probably wouldn’t work for deleted_at anyway).
Re: Easy, alternative soft deletion: `deleted_record_insert`
#7My question when people implement a generic feature like this, is why doesn’t the database do it? And many tunes, as is the case with soft delete, it does. For example, Redshift tombstones records and you can choose when to “vacuum” them up (actually delete them).
Usually if you’re changing the way a primary function of the database works, like delete, it’s probably not a good move.
Re: Easy, alternative soft deletion: `deleted_record_insert`
#8I did something similar to this many years ago but didn’t limit to deleted records and instead created an audit log with a very similar approach. It worked nicely and provided a view into how data was changing by our users.
Re: Easy, alternative soft deletion: `deleted_record_insert`
#9My question when people implement a generic feature like this, is why doesn’t the database do it? And many tunes, as is the case with soft delete, it does. For example, Redshift tombstones records and you can choose when to “vacuum” them up (actually delete them). Usually if you’re changing the way a primary function of the database works, like delete, it’s probably not a good move.
To take a stab at it:
This is one of those things where business requirements trump the technical implementation details. Prevailing theory is that actual deletes are bad because you can’t do historical analysis, recovery etc on the data. Say a customer stops using a service for a year but comes back: it’s a big win if you can (at least optionally) restore their data, so the theory goes.
That’s why tricks like this exist.
The alternative is to write the data to a separate database and/or table that’s meant for archive purposes. I think it’s better than these soft delete tricks but it’s got complexity too. More resilient IMO and let’s production systems run leaner over time IMO
Re: Easy, alternative soft deletion: `deleted_record_insert`
#10[flagged]