[javajosh]

The trade-offs between foreign key constraints vs none are almost identical to the trade-offs between static typing vs dynamic typing. Nowadays people realize that when they turn off these features is that they'll eventually have to re-implement them later.

[WJW]

You make this claim as if this happens to every company sooner or later, but if a company the size of GitHub can still do without ( https://github.com/github/gh-ost/issues/331#issuecomment-266...) it does become a little bit of a "you do not have google problems" type discussion.

(Perhaps you do have such problems, I don't know where you work! But 99%+ of companies don't have such problems and never will.)

[bigbizisverywyz]

>But 99%+ of companies don't have such problems and never will.

Not sure where you get your metrics, but I would say a more general rule would be that the more people work on an evolving product that includes code and schema changes, then the more you need db constraints to enforce what it means to have correct data.

If only 1 or 2 people are involved in a db that changes pretty infrequently then possibly in the long term you can get away with it.

But if you have a constantly evolving product which must carry new features, logic changes and additions to the schema, then I would say you definitely need db constraints - FK and column. It only takes a few different developers to decide that T,F,Y,N,TRUE,FALSE,YES,NO,Null,NULL,None all mean the same thing, and you've got a slowly evolving mess on your hands.

[mb7733]

I don't think that is a valid comparison. Static typing doesn't reduce throughput. It's almost the opposite.

[javajosh]

That's true. They are similar in that they enforce consistency, but yes one takes resources in the steady state.