[lugg]

Will result in corruption. Yes.

Will result in more fault tolerant software, also yes.

It's a trade off and one I make willingly at every scale.

I stopped using foreign keys after university and have never wanted them since.

Non nullable database fields are far more useful than worrying about fks.

[xref]

> Will result in more fault tolerant software

More fault tolerant because you have to waste time debugging the faults and monkeypatching them in code just to avoid FKs?

> Non nullable database fields are far more useful than worrying about fks

Can’t even count how many non-nullable fields I’ve seen packed with “” empty strings to get around that requirement

[lugg]

1. Over my career almost none of it has been debugging problems due to a lack of foreign keys.

Further to that, instead of having lazy cascading deletes moving the goal posts on you. Data missing its parent for example is an indication something is wrong. It's a useful diagnostic.

2. Most string data is safe to represent as empty. Handling null on the other hand is a different situation and often induces warnings or other side effects depending on the language. Forcing the null checking to your boundaries is much like forcing your state/mutation to the boundaries in FP. Hell eveb though I think it's insane, hexagonal arch works on this idea as well.