[aaron_m04]

> With foreign key constraints, you have to delete all related records when a parent record is deleted.

I've also seen good advice that you should never delete anything from your DB, but rather put rows in a different soft-deleted state...

[danpalmer]

This was clearly not legal advice. Soft-deletes come with a lot of complexity at the application layer, more maintenance, more security risk, and require building out user data deletion processes.

Having a deleted data table is a slightly easier approach I've seen, but you still need to be aware about user and legal requirements around deleting data.

[thayne]

> Soft-deletes come with a lot of complexity at the application layer, more maintenance, more security risk, and require building out user data deletion processes.

That depends on your application and requirements. I've worked on situations where a soft delete, where any fields with sensitive customer data are overwritten with a placeholder or random data (for legal compliance reasons) was a lot simpler than doing a hard delete and leaving a bunch of dangling records with ids pointing to records that no longer exist.

And unless your data model is pretty simple, and you are ok with not having any kind of grace period before fully deleting user data, you'll probably need to build a user data deletion process either way.

[hobs]

Exactly - there's a tension between keeping storage, performance, and cost.

Keep everything actually can make some things faster (though mostly slower) and give you a depth of information you didn't have, but has a big impact on storage and cost.

Most people pick some mix of tradeoffs - for the important things to audit keep every state change, for other ones get the backups out.