Why would you not want to enforce data integrity at the database level?

To enforce uniqueness, if you don't have the database do it, then your app is broken. I blogged about it here: http://blog.craz8.com/articles/2007/12/10/rails-validatesuniquenessof-is-completely-broken/

I think the foreign key constraint is a little harder to break, but there maybe scenarios where your DB may not be correct if you only use Rails.

PS: The forum seems to need a user account to participate. I like blog comments.

I use http://www.redhillonrails.org/#foreignkeymigrations to handle this. It will automatically create your foreign keys for you. One gotcha is that the order in which your tables are created is important. You can't create a foreign key to a non existing table. I haven't tried it in Rails 2.0 yet.

I think foreign key constraints are essential for a well developed app. I don't understand the current Rails' viewpoint that referential integrity should not be defined at the database level.

I think its just good programming sense to push constraints down to the lowest layer possible; and if necessary "bubble" those up to higher layers through some form of reflection. If the database is made authoritative WRT data types, constraints (foreign key and uniqueness), models could become much simpler because they'd be able focus on defining business logic and higher level constraints rather than low level stuff.

Wrong. Too many little things can slip through the cracks and considering it's hardly any effort, why not just do it? You'll sleep better :)

One example: validatesuniquenessof is shown to fail when two different processes both return that the record is valid to insert because at the time, they are - resulting in duplicates. DB constraints can stop this and return an error to handle.

I prefer to use FKs. A nice benefit is that the database creates an index on FKs, so you don't have to add them yourself -- and they're important because you select on those columns when fetching child objects. (post.comments will have an index on comments.postid if postid is a FK to posts.id.)

We use sexy migrations, which has a nice easy way to add foreign keys.

More detailed reply at http://jeronrails.blogspot.com/2008/01/you-should-use-foreign-key-constraints.html

@Jeremy: RE: database creating an index on foreign keys

Not all databases do this. SQL Server (well, up to 2000, maybe they changed it in 2005 or 2008) and PostgreSQL don't. While indexing can speed up foreign key validations, it's not necessary.

Yeah, I realized that Oracle and SQL Server don't index foreign keys. MySQL and Postgres do, though. I wasn't necessarily concerned with the speed of validation, but the speed of fetching child objects -- the objects that "belong to" another by having a FK to it.

By means of analytic unity, our a priori concepts can not take account of the objects in space and time.

The Transcendental Deduction, in so far as this expounds the universal rules of the empirical objects in space and time, abstracts from all content of knowledge.

Foreign keys are essential – I can’t tell you how many times I’ve run into a program that DOESN’T have foreign keys, and the other programmers I’m working with are shocked to find trash data in the database.

Getting down to the root of it all, the question of “should I use foreign keys?” is really “do I trust my code with not corrupting my database?”

There are so many problems that can go wrong in your code – do yourself a favor and stick in foreign keys. They take about 5 minutes at most to create, and they ensure that you can’t screw things up.