I understand that according to Rails philosophy, data integrity checks should be done at the application level as opposed to the database level. Like many other developers, I en
http://guides.rubyonrails.org/migrations.html#active-record-and-referential-integrity
"Although Active Record does not provide any tools for working directly with such features, the execute method can be used to execute arbitrary SQL. There are also a number of plugins such as foreign_key_migrations which add foreign key support to Active Record."
I found myself asking the same question the other day, so I did some research and collated my findings in an answer to an older but similar Stack Overflow question. I hope that's of use.
BTW, when you say that you "enthusiastically disagree" that data integrity checks should be done at the application level as opposed to the database level, I assume you mean that they should be done at both levels, rather than just at the database. I hope I'm right in thinking that virtually everyone agrees that having integrity checks at the application level is a Good Thing, and that the only topic being debated is whether they should additionally be done in the database.
It is for this reason that I (and the people who wrote Enterprise Rails - http://oreilly.com/catalog/9780596515201) recommend that you write your entire up and down migrations in SQL.
The advantages are:
There are disadvantages:
But, overall I reckon the advantages outweigh the disadvantages.
Quick example:
def self.up
execute <<EOS
create table .... (
....
);
EOS
end