钢轨上的外键一般都要避免吗?

这是一个神圣的问题,因为dhh(rails的创建者)之前已经声明,他认为数据库本质上是一个巨大的哈希表,所以不考虑通过使用诸如约束或存储过程之类的特性来利用数据库引擎擅长的一些东西。由rails纯粹主义者设计的rails。

也就是说,如果您希望强制数据的完整性与数据最接近,或者如果您的数据库被其他应用程序共享,那么就一定要使用其中一个插件来创建外键。毕竟,它会造成什么伤害,对吧?

除了约翰·托普利的回答之外,我做了一些研究,发现了DHH关于这个话题的一些想法,这让我读到了一篇有趣的文章:

• (军2006) DHH replies Teflon Ted的博客文章 Should we drink DHH's Kool-Aid?
• (2000年2月2006日) DHH replies in the comments (搜索“好的咆哮”)到某人对rails的咆哮
• (2006年5月) DHH replies to someone's request for migrations to support foreign keys
• (一月2006日) DHH explains why model associations don't belong in schema.rb

我找不到dhh将数据库称为“巨大的散列”,所以也许john正在改写另一个引语。我想读一本更新版的DHH的意见书。

在过去的几年里,我没有从别人那里得到太多的意见。以下是我找到的:

• (2011年7月) CodeGenesys explain why and how they use foreign keys in Rails
• (2008年1月)一篇题为 You Should Use Foreign Key Constraints in Rails
• (11月2007) a useful blog post which contains more useful research on the pros and cons of foreign keys

rails并不阻止您在数据库中使用外键约束,它只是在默认情况下不会将它们提供给您。“rails方式”是依赖rails来管理数据库、级联删除、强制引用完整性等。

有几个插件可以向迁移添加外键约束,但我通常选择手动添加它们。假设您已经创建了createusers和createposts迁移,则可以添加“linkpoststousers”迁移:

# Assumes PostgreSQL
class LinkPostsToUsers < ActiveRecord::Migration
  def self.up
    execute "
      ALTER TABLE posts 
        ADD CONSTRAINT fk_posts_user_id
        FOREIGN KEY (user_id) REFERENCES users(id)
        ON DELETE CASCADE
        ON UPDATE CASCADE"
  end

  def self.down
    execute "ALTER TABLE posts DROP CONSTRAINT fk_posts_user_id"
  end
end