Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding the soft delete anti-pattern

cultured.systems

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Avoiding the soft delete anti-pattern

#32

Post by darkwater »

kthejoker2 wrote: post #13

The main problem I have is the article takes a performance/devlopment lens to soft deletes, and only pays lip service to the objectives you're trading off performance for with soft deletes ... namely data retention / disaster recovery / audit requirements. * availability / recovery - soft deletes provide the best RPO/RTO in archival / lifecycle planning * auditability / compliance - much easier to achieve with 1 syst…

Well, compliance (as in GDPR) might actually force you to not soft-delete in some cases.

Re: Avoiding the soft delete anti-pattern

#33

Post by janee »

Reefersleep wrote: post #4

How about a separate, schema-wise identical "deleted_x" table that you "move" deleted entities to? Can't get much more explicit than that, and still enables whatever joins you'd like on historical deleted data.

There is the downside of having to maintain both schemas now.

Unless you automate it devs will have to remember to migrate both when making a change which adds some overhead, not a lot, but it's just something to consider here imo as some migrations (schema and/or data) can become nasty and complex

Re: Avoiding the soft delete anti-pattern

#34

Post by oxidant »

EdwardDiego wrote: post #21
kthejoker2 wrote: post #13

The main problem I have is the article takes a performance/devlopment lens to soft deletes, and only pays lip service to the objectives you're trading off performance for with soft deletes ... namely data retention / disaster recovery / audit requirements. * availability / recovery - soft deletes provide the best RPO/RTO in archival / lifecycle planning * auditability / compliance - much easier to achieve with 1 syst…

Yeah, before breaking out Debezium, Kafka Connect and S3, consider soft delete first. It might not scale, but maybe you don't need to scale just yet, and maybe a column called is_deleted is far more appropriate and far less complex for your current purposes.

IMO deleted_at, either with null or epoch as the "not deleted" value is nicer than is_deleted because it allows some level of auditing.

Re: Avoiding the soft delete anti-pattern

#36

Post by GMoromisato »

Isn't soft-delete just a variant of having a lifecycle? The article tries to distinguish it by saying that the lifecycle pattern is implemented at the app-layer instead of the database layer, but isn't their criticism of soft-delete that the app-layer has to deal with it?

Maybe a better recommendation is to give guidelines for implementing soft-delete?

Re: Avoiding the soft delete anti-pattern

#39

Post by throwaway894345 »

minimeme wrote: post #38

But what about data overwrites? This is basically the same as deleting data, since information will be destroyed. Using soft delete is a somewhat naive solution if there is no mechanism for restoring overwritten data.

Append-only tables are my preference. If you're worried about infinitely growing space, you can have some garbage collector clean up the least relevant records periodically for very little cost.
Post reply on HN