Hacker News Reader

Comment by BenoitP | Hacker News Reader

My rule of thumb has been: enable them strictly in DEV and INT environments, disable in PROD. They can catch schema discrepancies, but can impede ingestion rates.

Also some referential errors are sort of ok in PROD, as long as it's only about not dropping user data; which can be dealt with later on (INT gets reset with PROD user data from a backup each week, it also helps in the restore plan, fk are enabled, errors are caught, then data gets pruned heavily)

If referential integrity is a business-level bug, then of course we should enable them.

View on HN

To me that seems like an invitation for catastrophic bugs or problems to creep through and surprise you in prod, since the lower envs are running different a different configuration.

I suppose it's entirely dependent on the type of data you're working with though.

> as long as it's only about not dropping user data

Can you tell the name of the company? It's for my lawyer.

Whatever you do, always have your dev/test environment identical to production.

Have a load balancer or replication in prod? You must have the same when you test.

Otherwise, you will have a bad time m'kay.

And don't get me started about removing fk constraint, anybody doing that on purpose is either very, very smart, either very, very ignorant/inexperienced.

Very interesting! Thanks for sharing

>My rule of thumb has been: enable them strictly in DEV and INT environments, disable in PROD

I mean I think the constraints should be on in all environments, but disabling them in prod but not dev seems utterly backwards? Protect your test data from getting corrupted but not your actual customer data?

I assume the idea is that data corruption issues will be spotted in dev testing.

That sounds like a terrible assumption to stake your business on though, especially for what are really marginal gains for the 99% of companies who don't need the tiny performance boost from not having foreign keys.

Reply on news.ycombinator.com