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