"Agile Web Development with Rails" by Dave Thomas, page 322:
You can choose to to establish these [foreign-key] constraints if you
want (and I personally recommend that you do), but the foreign-key
support in Rails doesn't need them.
"The Rails Way" by Obie Fernandez, page 296:
... we haven't really touched on a subject of particular importance to
many programmers: foreign-key constraints in the database. That's
mainly because use of foreign-key constraints simply isn't the Rails
way to tackle the problem of relational integerity.
I know there won't be unanimous consensus on this topic, but is there
a "Rails Way" concerning foreign keys? If "The Way" is not to use
them, what do we use?
Database constraints, when violated, shoot back an exception to the
rails app at run time.
This is good for debugging and development. It's like compiling in
'DEBUG' mode. But this would be bad in production. Your customers
will not be happy to see a rails error/exception page. They are
ugly. On the other hand, if the app is coded 'correctly', it will
never happen at run time unless something else (like a hardware
failure) corrupts the database. Since it will 'never' happen, it is a
moot point. If a tree falls in the forest...
On the other hand, how many apps are coded 'correctly'? If your
customers are complaining about nasty 'exception' pages, you can fix
the problem more quickly than if you let the corruption continue to
spread throughout the database.
On the other, other hand, if a true hardware glitch results in a rails
exception page, the users will blame you. But a true hardware glitch
is so rare that it probably is your fault anyway.
This is an engineering trade-off that depends.... blah, blah, blah...
I would love to see FK constraints in a RDBMS, however, I, personally,
have never seen this. Maybe in Oracle? I wonder if it's a pipe dream
(for it to work correctly).