|
Your choice of adjective "irrelevant" is amusing.
"Bad" or "wrong" might be better.
The purpose of foreign keys is to ensure
one aspect of data integrity.
There are actually several types of data integrity:
entity integrity, which ensures that every
entity can be uniquely identified (implemented via primary keys) domain integrity, which ensures that
attribute values are chosen only from a specific set of
allowed values referential or relational integrity, which ensures
that every foreign key is either NULL (if allowed) or contains
a value that matches some value of the related primary key
If you attempt to enforce relational integrity without
an actual foreign key defined in the database, then you run
the risk of having a "broken link" or "orphan record" in the
database. In other words, data integrity will be violated,
your database will have bad data, and your users will get angry (or worse).
You will never be certain that your front end program
will be the only means for changes to enter the database.
It's just too big a risk. Furthermore, you are spending
unnecessary and likely substantial time and effort to create logic
which the database has built in. You are re-inventing the wheel
for no good reason.
There can never be "too many" foreign keys. They are either required
by the business rules, or not. If they are required (for example, to ensure
that every order belongs to a known customer), then you must implement them.
Performance is not the issue. Without foreign key checking,
your queries might run a few picoseconds faster, but if the database
then contains bad data, how long will your users tolerate such a
situation?
Trust me, it is far, far better to use foreign keys for their intended
purpose than to try to do it yourself or try to get away without them.
|
