Do you absolutely need foreign keys in a database?

Question

I was wondering how useful foreign keys really are in a database. Essentially, if the developers know what keys the different tables depend on, they can write the queries just

Answer 1

Folks have offered up some good answers above. However, one important point I didn't see mentioned is that foreign keys make your entity relationship diagrams (ERDs) easier to generate and much more meaningful. Without FKs, you either need to depict the FK relationships on your ERD manually (painful for you) or not at all (painful for others, and perhaps even for yourself once your memory of the implied FK relationships starts to fade over time). With FKs explicitly defined, most tools that automatically generate ERDs from database object definitions will automatically detect and depict the FK relationships. I hope this helps.

Answer 2

I think that assuming that programmers will always preserve data integrity is a risky assumption.

There's no reason why you wouldn't create foreign keys, and being able to guarantee integrity instead of just hoping for integrity is reason enough.

Answer 3

Use constraints rather than application logic to enforce integrity because it is generally easier, cheaper and more reliable to maintain constraints in one place (the database) rather than in every application.

I understand from one of your comments that your motivation for asking the question is that you think leaving out the keys may make it easier to evolve the database design during development. In my experience you are wrong about that. I find that it's actually better to be more restrictive with constraints in the early stages of development. If in doubt, create the constraint because it's much easier to remove constraints later than it is to create them. Removing a constraint will tend to break fewer things than adding one and generally requires less testing and fewer code changes to achieve.

Answer 4

You don't have to use them but why wouldn't you?

They are there to help. From making life easier with cascade updates and cascade deletes, to guaranteeing that constraints aren't violated.

Maybe the application honors the constraints, but isn't it useful to have them clearly specified? You could document them, or you could put them in the database where most programmers expect to find constraints they are supposed to conform to (a better idea I think!).

Finally, if you ever need to import data into this database which doesn't go via the front-end, you may accidently import data which violates the constraints and breaks the application.

I'd definetly not recommend skipping the relationships in a database

Answer 5

If you don't care about referential integrity then you are right. But.... you should care about referential integrity.

The problem is that people make mistakes. Computers do not.

Regarding your comment:

but say for example, the programmers do a good job of preserving data integrity

Someone will eventually make a mistake. No one is perfect. Also if you bring someone new in you aren't always sure of their ability to write "perfect" code.

In addition to that you lose the ability to do cascading deletes and a number of other features that having defined foreign keys allow.