I encourage you to read my comment again, and point out where I mentioned merely setting a delete flag. Any reader worth their salt will point out that it’s not what I suggested at all.

Wouldn't it be possible to just delete the 'idetifiabel' parts in the database in order to be GDPR compliant?

If you for instance save all the user data like user preferences under a random userId, and then delete the personal data (such as email address, name etc.) associated with the userId I would expect this to be GDPR complaint without having to do a cascading delete.

To your post specifically, I think a cascade of "zero outs" or the like to blank out a user's data would be sufficient is it not? It could happen at most once for each user account so it shouldn't be ruinously inefficient unless a system was already on the verge of collapse.

But on the topic in general, could someone explain to me what the real world consequences are likely to be for a small business not based in the EU, of not complying? If I've never cared where my users were as long as their payments cleared (oh, is that where they get you? the payment processor?), and I'm selling handcrafted bobbins online in Canada without letting people delete their email address, what is likely to happen if someone complains to EU authorities?

HN won’t let me go deeper, so here it goes:

> "you could easily not switch to a CASCADE, but instead set delete=1 and mark every sensitive field with a special value"

Emphasize on the part after “and”

The thing is, affected persons can not only request a data deletion, but also the pausing of data processing. In that case, you are not allowed to delete them but they must not be used any longer, which is essentially a soft delete. So to be compliant, you’d have to implement both a soft and a hard delete.

I read a lot about cascading deletes, which I interpret as holding personally identifiable data redundantly.

I can see two reasons why this would be a problem:

You have a really shitty un-normalized database design. Granted that you may have to denormalize specific columns for performance reasons. But why that would be the case with, for example names, phone numbers or sexual preferences, totally escapes me.

Or, you're referring to actual cascading deletes, meaning that you need to get rid of child relations, based on deletion of the parent relation. If this poses a problem then I'd argue that you're guilty of a shitty database implementation, arguably with criminally bad definition of your primary / foreign key pairs.

I really don't see a problem here, unless the database schema is implemented in a totally incompetent manner.

Edit: Clarity

A cascading delete is not necessary. You need only to remove personal information, not all information. Now if you are producing an application that only contains personal information like a chat app, then sure, you might need to remove everything.

But often all you need to do is overwrite the name, address, or similar bits of information, and you can then leave the rest of the data intact and set your delete flag.