Question

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 enthusiastically disagree.

I’ve found a lot of discussions addressing this problem but they all seem to be old and, dismayingly, they seem to point to divergent solutions.

I have to imagine there’s a de-facto standard way of doing foreign key constraints in Rails 3. However, whatever it is (if it does exist) seems to be smothered by all the past discussions because I can’t find it.

Are Rails developers by this point mostly on the same page with foreign keys? If so, I would love to know how they’re generally handled.

Answer 1

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:

• The ability to add foreign keys on table creation – without a separate alter table
• It allows you to use database specific field types – like tsvectors
• It allows you to add different types of indexes – like Gin or Gist
• It allows you to write functions and/or triggers
• You wont have to remember what DSL type relates to what SQL field type – e.g. :number

There are disadvantages:

• It’s not database agnostic (who cares and how often will you change your database?)
• It’s not Ruby (but every good Rails developer should know SQL, right?)

But, overall I reckon the advantages outweigh the disadvantages.

Quick example:

  def self.up
    execute <<EOS

create table .... (
  ....
);

EOS
   end