RI should be in the app - Apps come and go, 5 years ago it was a Perl
CGI app, then came PHP just before some pointy haired boss decided
J2EE was the way to go. I bet that in all this time the database
structure hardly changed at all. Lets not get started on all the
various back end processes that may need to talk to this database to
do their thing etc.
Apparently, no one has referred to these two (short) articles by Martin
I'd say that Rails being opinionated considers databases to be the
property of their applications. As elsewhere in Rails, you can work
around this opinion, but conforming to it leads you on the path of
Regarding sharing database content, Rails has an opinion, too: Offer a
service to interact with this content. Doing so is the best way to
ensure that the rules of your domain are enforced. These rules can
hardly be expressed through referential integrity constraints alone.
So, unless you're going to put all the business logic in the database,
a service looks like the right thing.
The database simply must protect the data -
constraints and foreign keys are the way forward here (I tend to
avoid triggers like the plague).
As I say above, I think it is quite questionable whether the database
*can* protect the data sufficiently using only these means.
All that said, I'm very much in favor of checking RI and NOT NULL in the
database. It's not even particularly complicated. Have a look at
The only snag I can think of is that FK constraints can bite you when
loading fixtures for testing. AFAICT, when using foreign key
constraints, there's currently no way to load fixtures containing
This problem might be solvable by changing Fixtures#create_fixtures so
that it issues
SET CONSTRAINTS ALL DEFERRED
to databases that support it. I haven't tried this, however, and as I
don't need it currently, I'm not going to investigate it right now. So,
if anyone wants to beat me at it, go ahead.