4 ms·

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 rate

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.

shayonj 3y ago
Very interesting! Thanks for sharing
somehnguy 3y ago
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.
LtWorf 3y ago
> as long as it's only about not dropping user data Can you tell the name of the company? It's for my lawyer.
HideousKojima 3y ago
>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?
- solumunus 3y ago
  I assume the idea is that data corruption issues will be spotted in dev testing.
  - HideousKojima 3y ago
    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.
whynotmaybe 3y ago
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.

shayonj 3y ago

Very interesting! Thanks for sharing

somehnguy 3y ago

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.

LtWorf 3y ago

> as long as it's only about not dropping user data Can you tell the name of the company? It's for my lawyer.

HideousKojima 3y ago

>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?

solumunus 3y ago
I assume the idea is that data corruption issues will be spotted in dev testing.
- HideousKojima 3y ago
  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.

whynotmaybe 3y ago

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.