[devmor]

I use FKs because I have built my career on refactoring old software.

I have seen over and over firsthand the kinds of data integrity problems that come from leaving the decision to the business software and those who meddle asynchronously with data.

You can always rewrite software. Rewriting bad data is not only difficult but often impossible.

[steve_gh]

This:

"You can always rewrite software. Rewriting bad data is not only difficult but often impossible."

[charcircuit]

>You can always rewrite software. Rewriting bad data is not only difficult but often impossible.

Isn't that an argument against FKs? It's easier to rewrite the software to handle FKs than to deal with trying to setup FKs with bad data since it's difficult to fix.

[dmak]

Data often outlives the teams that input it. Often the case is, you can't recapture that domain knowledge to rebuild the missing data.

[CRConrad]

> >You can always rewrite software. Rewriting bad data is not only difficult but often impossible.

> Isn't that an argument against FKs?

No, it's an argument for FK checks.

> It's easier to rewrite the software to handle FKs

Except once you have that bad data, you don't know what to do to fix it in whatever language your app is coded in any more than you do than in SQL. Once you know that, you can just as well do it in SQL as in any other language. Or, if it's just that you know that language better than the SQL language, by all means write a separate one-time fix-the-data app in that language, run it once to fix the data...

And then enable the FK checks so you won't have to do it again.

> than to deal with trying to setup FKs with bad data since it's difficult to fix.

Which is why you want FK checks in your DB from the beginning.

[Edit: Fix bad original editing.]