[morganpyne]

How does this deal with foreign key references? I thought that if you rename a table the FK references from other tables will still point at the renamed table? Discussion here: http://dev.mysql.com/doc/refman/5.0/en/rename-table.html

The Percona pt-online-schema-change tool goes to great lengths to avoid this kind of problem.

[c3]

Basically, it doesn't - because it doesn't need to. Rails/ActiveRecord doesn't use those either. Problem solved :)

[morganpyne]

Interesting. As you have probably guessed by now, I'm not a Rails developer and therefore did not know this. I was surprised to read about this after your comment and find that Active Record went the lowest common denominator route with this and therefore gave up any native foreign key integrity support.

[JonnieCache]

There is nothing to stop you using foreign key constraints with rails, the activerecord migration api includes methods to create them for the major db adapters and there are plugins to automate the process to some extent. It's not the Rails Way™ because it sacrifices some database-agnosticity, and therefore almost noone does it. People achieve the same behaviour with application-level validations in the model.

I'd wager that a lot of the big professional rails deployments are doing FK constraints though.

[jaylevitt]

The gem 'foreigner' makes them painless, and supports Postgres, Oracle, and I think MSSQL.

[lectrick]

I have never missed foreign keys on the projects I've worked on that don't use them.

This is because those projects typically sit on databases that are only expected to be accessed via web API and not directly from some other source.

Which is basically the Rails philosophy. Only let the app talk to the DB, and let the only outside interface to the DB be through the ORM that has to do most of the data validations anyway.